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[57] ABSTRACT 

An airline seat reservation system wherein seat reserva- 
tions are controlled using, in part, a computerized seat 
inventory control system. The seat inventory control 
system, based on a concept termed Network-Based 
Expected Marginal Seat Revenue (EMSR), does not 
require the large number of variables required by the 
other network-based approaches, and it incorporates a 
probabilistic demand model without resorting to com- 
putationally intractable integer programming. The seat 
inventory control system uses iterative leg-based meth- 
ods to control bookings in a flight network comprised 
of a plurality of itinerary/fare class combinations using 
a plurality of flight legs. When considering a particular 
flight leg, the total fare paid by a passenger using the leg 
is adjusted by taking into account an estimate of the 
displacement cost of the travel on the other legs of the 
itinerary to create a virtual fare. Expected margitmi seat 
revenues (or more precisely, their current approxima- 
tions) provide the displacement costs on the legs when 
computing virtual fares. Using these virtual fares, a 
leg-based optimization method is applied to the individ- 
ual legs one-by-one to compute new approximations of 
the expected marginal seat revenues. This method is 
iterated until the expected marginal seat revenues con- 
verge to their network-optimal values. 
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nue method to determine optimal seat allotments by fare 

VIRTUAL FARE METHODS FOR A type," Proceedings of the 22nd AGIFORS Symposium, 

COMPUTERIZED AIRLINE SEAT INVENTORY 1982, pp. 339-362; P. P. Belobaba; "Air travel demand 

CONTROL SYSTEM and airline seat inventory management," Technical 

5 Report FTL-R87-8, Flight Transportation Laboratory, 

BACKGROUND OF THE INVENTION Massachusetts Institute of Technology, Cambridge, 

1. Cross Reference To Related Applications Mass., May 1987; P. P. Belobaba, "Application of a 
This application is a continuation-in-part of patent probabilistic decision model to airline seat inventory 

application Ser. No. 07/630,261 filed Dec. 19, 1990 by control:, Operations Research, 37 (1989), No. 2, pp. 

Scot W. Hornick et al. entitled "AIRLINE SEAT IN- 10 183-197). 

VENTORY CONTROL METHOD AND APPARA- Other methods are network-based, but assume a de- 

TUS FOR COMPUTERIZED AIRLINE RESER- terministic demand model, i.e., they assume that de- 

VATION SYSTEMS", which application is incorpo- mand for air travel in a particular market is known 

rated herein by reference. precisely without any uncertainty (see, e.g., the follow- 

2. Field Of The Invention 15 ing publication, which is incorporated herein by refer- 
This invention relates generally to an airline reserva- ence: F. Olover, R. Glover, J. Lorenzo, and C McMfl- 

tion system. In particular, the present invention pro- lan, 'The passenger-mix problem in the scheduled air- 

vides an airline seat inventory control system for com- lines," Interfaces, 12 (1982), pp. 73-79). Such methods 

pmerized airline reservation systems. do not reserve enough seats to capture higber-than- 

3. Description Of Related Art 20 average demand for the more expensive fare classes. 
Strategic and operational planning for commercial Further, these methods use linear programming fonnu- 

airlines are highly complicated problems, especially lations with large numbers of variables (and concomi- 
since the industry has been deregulated. In order to xanl\y time-consuming solutions) to determine the book- 
cope with this complexity, computer-based decision ing fom\s for each fare class. Efforts to simultaneously 
support systems have been adopted to facilitate the 25 &chitve network-wide optimality and account for the 
planning of schedules, routes, aircraft and crew rota- prob abilistic nature of demand have resulted in 0-1 
tions and yield management. Yield (or revenue) man- mt programming formulations with an even larger 
agement is one of the most important aspects of the number of varia bles (see, e.g., the following publication, 
operational plan for a commercial airline. Yield man- whkh fa mcon)0rated herein b re ference: R. D. 
agement can be separated into two distinct parts: pnc- 30 ^ „ An £ rline rescrvadon modcl for opening 

' "2? $i **\ lnv ^ tor y i contro1 - P t nc ?"e l T ^ and closing fare classes," Unpublished Internal Report, 

establishment of fare classes and tariffs within those w _ f. . J T n , - , r 

classes for each specific origin-destination market. Seat McD°nneU-Douglas Corporation . Long ; Beach, Cahf., 

inventory control is the periodic adjustment of nested ™ 5) :™ e l ?? e nmn ^f Vf ?*f T P 

booking limits for the various fare classes so as to opti- 35 Itv * the ««««» methods make these approaches un- 

mize the passenger mix and thereby maximize the gen- for i-^wwM problems, 

erated revenue. In particular, the objective is to fly the SUMMARY OF THE INVENTION 
aircraft as full as possible without allowing the earlier- 

booking, discount-fare passengers to displace the later- To overcome the limitations in the prior art discussed 

booking, full-fare passengers. 40 ab °ve, md to overcome other limitations readily recog- 

Recently, considerable research has been devoted to nizab,e to skilled m the the P resent invention 
developing automated seat inventory control methods discloses an airline reservation system wherein reserva- 
(For a survey, see the following publications, all of tions are controlled using, in part, a seat inventory con- 
which are incorporated herein by reference: P. P. tro1 system. The present invention provides an airline 
Belobaba, "Airline yield management, an overview of 45 reservation system that produces optimal network- 
seat inventory control," Transportation Science, 21 wide seat inventory controls while taking into account 
(1987), no. 2, pp. 63-72; For a comparative evaluation the probabilistic nature of demand. The present inven- 
see E. L. Williamson, "Comparison of the optimization ton, based on a concept termed Network-Based Ex- 
techniques for origin-destination seat inventory con- pected Marginal Seat Revenue (EMSR), does not re- 
trol," Technical Report FTI^R88-2, Flight Transporta- 50 q™re the laf g e number of variables required by the 
tion Laboratory, Massachusetts Institute of Technol- other network-based approaches, and it incorporates a 
ogy, Cambridge, Mass., May 1988). However, the pro- probabilistic demand model without resorting to com- 
posed methods all have serious limitations. putationally intractable integer programming. 

Some methods are teg-based and therefore do not In the present invention, a computer-based seat in- 

produce booking limits that are optimal in a system- 55 ventory control system uses iterative leg-based methods 

wide sense. For example, the "locally greedy" ap- to control bookings in a flight network comprised of a 

proach used by these methods may not recognize the plurality of itinerary/fare class combinations using a 

additional revenue generated by long-haul (multi-leg- plurality of flight legs. When considering a particular 

itinerary) passengers versus short-haul (single-leg-itin- flight leg, the total fare paid by a passenger using the leg 

erary) passengers, or, on the other hand, they may have 60 is adjusted by taking into account an estimate of the 

an uneconomical bias to long-haul passengers (see, e.g., displacement cost of the travel on the other legs of the 

the following publications, all of which arc incorpo- itinerary to create a virtual fare. Expected marginal seat 

rated herein by reference: K. Littlewood, "Forecasting revenues (or more precisely, their current approxima- 

and control of passenger bookings," Proceedings of the tions) provide the displacement costs on the legs when 

12th AGIFORS Symposium, 1972, pp. 95-117; A. V. 65 computing virtual fares. Using these virtual fares, a 

Bhatia and S. C. Parekh, "Optimal allocation of seats by leg-based optimization method is applied to the individ- 

fare," Presentation to the AGIFORS Reservation ual legs one-by-one to compute new approximations of 

Study Group, 1973; H. Richter, "The differential reve- the expected marginal seat revenues. This method is 
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iterated until the expected marginal seat revenues con- FIG. 24 is a flow chart describing the CONSTRUCT 

verge to their network-optimal values. VIRTUAL FARES in the nested EMSR-difTerential 

virtual fare method; and 

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 25 is a flow chart describing the FIND INTER- 

In the drawings, where like numerals refer to like 5 SECTION routine in the nested EMSR-difTerential 

elements throughout the several views: virtual fare method. 

FIG. 1 is a block diagram describing the components DETAILED DESCRIPTION OF THE 

of an integrated operation and strategic planning system PREFERRED EMBODIMENT 

using the inventory control method and apparatus of . 

the present invention; 10 In the following Detailed Description of the Pre- 

FIG. 2 is a flow chart describing the logic of an iter- « "red Embodiment, reference * made to teng 

fttMl w hftsed method- nymg Drawings which form a part hereof, and in which 

fS 3 is an illustration of two cases for the solution « shown by way of illustration Are* ™bodtoems in 

" » which ^ mventl0n may be practiced. It is to be under- 

ofBquaUon(8)mfra^ 15 Ktood that other embodiments may be utilized, and 

FIG. 4 is a flow chart describing the logic of an iter- lJ . . ^ ... # . v- . „„„ , nr i 

. , ^ . , . _.f- n , . chances may be made to both the that process ana tne 

ated^ leg-based method for EMSR-prorated virtual ^ ^ ^ of prcs- 

3 G ;JUV fl ° W Chan * C bgiC ° f ^cTrSt invention is an airline seat reservation 

GET INPUT routine; ... . 20 system wherein seat reservations are controlled using, 

r V s ^ mCd B fl ° W Chart dcSCnbmg ^ in part, a seat inventory control system. The present 
logic of the INIT routine; invention provides optimal seat reservation control 

FIG. 7 is a flow chart describing the logic of the network-wide booking controls while taking into 

CONSTRUCT MILE PRORATED FARES routine ™ g u |^ of demand. Tnf seat 

in the unnested EMSR-prorated virtual fare method; ^ rescrvalion control, based on a concept termed Net- 

FIG. 8 is a flow chart describing the logic of the work .Based Expected Marginal Seat Revenue 
CONSTRUCT MILE PRORATED FARES routine (emsr), docs not >equire the large number of variables 
in the nested EMSR-prorated virtual fare method; required by the other network-based approaches, and it 

FIG. 9 is a flow chart describing the logic of the i ncor porates a probabilistic demand model without 
CONSTRUCT MILE PRORATED FARES routine ^ resorthlg t0 computationally intractable integer pro- 
in the nested EMSR-difTerential virtual fare method; gamming as compared in Table 1. 

FIG. 10 is a flow chart describing the MAIN routine retailed Description is organized into eight 

in the unnested EMSR-prorated virtual fare method; sections. In the first section, entitled "An Airline Seat 

FIGS. 11A and 11B combined are a flow chart de- Reservation System", the basic components of an air- 
scribing the CALC LAMBDA routine in the unnested 35 line ^ reservation system are described, illustrating 
EMSR-prorated virtual fare method; how the seat inventory control system can be integrated 

FIGS. 12A and 12B combined are a flow chart de- mto sucn a system. The seat inventory control system 
scribing the CALC LIMITS routine in the unnested generates the information necessary to set booking lim- 
EMSR-prorated virtual fare method; its for the airline scat reservation system. 

FIG. 13 is a flow chart describing the CONSTRUCT ^ X n the second section, entitled "A Mathematical For- 
VIRTUAL FARES routine in the unnested EMSR- mulation", the mathematical formulation of the un- 
prorated virtual fare method; nested network-based seat inventory control problem as 

FIG. 14 is a flow chart describing the DELFUNC a constrained nonlinear optimization problem is de- 
routine; scribed. The optimum is characterized by a relatively 

FIG. 15 is a flow chart describing the UPDATE 45 small system of nonlinear equations. 
VIRTUAL FARES routine in the unnested EMSR- i n the third section, entitled "Solving The System 
prorated virtual fare method; With Virtual Fares And A Leg-Based Method," it is 

FIG. 16 is a flow chart describing the BINARY rou- described how the system of equations characterizing 
tine; the unnested network optimum can be solved by iterat- 

FIG. 17 is a flow chart describing the MAIN routine 50 ing a leg-based method and using EMSR-dependent 
in the nested EMSR-prorated virtual fere method; virtual fares. 

FIG. 18 is a flow chart describing the CALC In the fourth section, entitled "Incorporating Nesting 
LAMBDA routine in the nested EMSR-prorated vir- In The Optimization Model," the uses of nested avail- 
tual fare method; ability in the optimization model are described. 

FIG. 19 is a flow chart describing the CONSTRUCT 55 In the fifth through eighth sections, the implementa- 
VIRTUAL FARES routine in the nested EMSR- tion of three embodiments of the airline seat inventory 
prorated virtual fare method; control is described. 

eJ2£™ S " fl0W ^descriWng^enmiNTCR- R^tic System 

SECTION routine in the nested EMSR-prorated vir- 
tual fare method; 60 FIG. 1 describes the elements of an airline seat reser- 

FIG. 21 is a flow chart describing the operation of the vation system 1 according to the present invention. The 
UPDATE VIRTUAL FARES routine in the nested reservation system 1 is a software system that is exe- 
EMSR-prorated virtual fare method; cuted by a computer 2. The reservation system 1 com- 

FIG. 22 is a flow chart describing the MAIN routine municates with a plurality of remote terminals 3 and 
in the nested EMSR-differential virtual fare method; 65 printers 4. The reservation system 1 accepts or rejects 

FIG. 23 is a flow chart describing the CALC seat reservation requests and records those reservations 
LAMBDA routine in the nested EMSR-difTerential 10 in a database 9. In the present invention, a seat inven- 
virtual fare method; torv control software system 5 uses a flight network 
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database 6 to generate seat booking limits. 7 and/or -continued 
expected marginal seat revenues (EMSRs) 8 for input to 

the reservation system 1. The reservation system 1 relies ^ " ffe/ J (vj ~ VJ ~ 
on this data 7 and 8 to determine whether to accept or 

reject seat reservation requests. 5 wnere in x is an independent variable, tj is a jth largest 

The database 6 describes a flight network comprising fare OT i eg a, and vj is a probability that more 

a plurality of flight legs a, and itinerary p and fare class ^ q passen g e rs are willing to pay fj or more to 

i combinations. Each flight leg a has a residual seating travel on leg a. The above steps are repeated for the 

capacity Q, and each itinerary p and fare class i combi- J() particular flight leg a until the EMSR K, 8 converges, 

nation has a revenue yield iff for a seat reserved therein. The above steps are repeated for all flight legs a until 

Using an unnested EMSR-prorated virtual fare the changes in EMSR's Xo's therefor are insignificant 

method of allocating seats in a computerized airline Using a nested EMSR-difTerential virtual fare method 

reservation system, the system calculates an initial ex- of allocating seats in a computerized airline seat inven- 

pected marginal seat revenue (EMSR) Xfl8 for all flight 15 tory control system, the system calculates an initial 

legs a. An unnested EMSR-prorated virtual fare vpj is expected marginal seat revenue (EMSR) A* 8 for all the 

computed for every itinerary p and fare class i combina- flight legs a. A nested EMSR^ifferential virtual fare 

tion that contains a particular flight leg a having a non- v^'* is computed for each itinerary p and fare class i 

zero residual seating capacity Q, so that: combination that contains a particular flight leg a hav- 

20 ing a nonzero residual seating capacity C so that; 



J ill** 



25 



bcp " 



A new EMSR X*, 8 for the particular flight leg a is 
calculated based on the virtual fares v p J by applying The itinerary p and fare class i combinations are sorted 
Newton's method to a seating capacity constraint for into a list ordered by descending virtual fares v p J. The 
the particular flight leg a: sorted list of virtual ifares VpJ is processed one-by-one 

3 Q to find an intersection point defining a new EMSR X<, 8 
for the particular flight leg a between functions: 

thereby ensuring that a total number of seats assigned to 35 ~ ? fj (vj - 17- 1) 

the itinerary p and fare class i combinations are equal to f<f^ x 

the residual seating capacity of the particular flight leg . „ ... 

a, wherein the virtual fares v,/are updated at each step * "* ^dependent variably U is a jtt. argest 

of the Newton's method stace each step changes the m ^ fare on ,c « "■ "**J » • ^^V^^J 
_ wnTl . . . n . . , -T , 6 ^ 40 than passengers are willing to pay the virtual fare \<J 

EMSR \q for the pardcular flight leg a. The above steps Qr ^ Qn a ^ ^ m ^ 

t r M ep ^ Particular flight leg a until die for all flight legs a until changes in EMSR's \Ss 8 there- 

EMSR \ a 8 converges. The above steps are repeated for for m insignificant. 

all flight legs a until the changes in EMSR's X^'s 8 there- Operators at the reservation terminals 3 enter a seat 
for are insignificant. 45 reservation request for a particular itinerary/fare class. 

Using a nested EMSR-prorated virtual fare method The computer 2 receives the seat reservation request 
of allocating seats in a computerized airline seat inven- f rom the reservation terminals 3 and the airline reserva- 
tory control system, the system calculates an initial tion system 1 accepts or rejects the seat reservation 
expected marginal seat revenue (EMSR) K, 8 for all the request. 

flight legs a. A nested EMSR-prorated virtual fare v PfQ 50 Two different paradigms may be used for determin- 
J *is computed for each itinerary p and fare class i combi- ing availability, i.e., allocation-based availability and 
nation that contains a particular flight leg a having a value-based availability. In allocation-based availability, 
nonzero residual seating capacity C a so that: bookings are compared to a booking limit or authoriza- 

tion level, so that the seat reservation request is ac- 
55 cepted when the total number of seats 7 assigned to the 
A itinerary p and fare class i combinations is not exceeded . 

V B j jij In value-based availability, the generated revenue is 

compared to a sum of expected marginal seat revenues, 
, . so that the seat reservation request is accepted when the 

The itinerary p and fare class 1 combinations are sorted ^ seat reservation request would yield revenue greater 
into a list ordered by descending values of virtual fares ^ or t0 a sum of ^ EMSR's Kj 's 8 for all flight 
\ p J. The sorted list of virtual fares \ P J is processed j egs a m tne itinerary p. 

one-by-one to find an intersection point defining a new j± electronic status message indicating acceptance or 
EMSR Xj 8 for the particular flight leg a between func- rejection of the seat reservation request is transmitted 
tions: 65 by the airline seat reservation system 1 to the reserva- 

tion terminal 3. If accepted, the seat reservation request 
^ m x . is recorded in the database 9 and a ticket may be printed 

on the printer 4 attached to the terminal 3. 
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wherein Xi, is the expected marginal seat revenue 
II. A Mathematical Formulation (EMSR) for leg b and Qf p (.) is the inverse of the cumu- 

1. Deriving the Network Equations lative probability density function of demand for fare 

Hie network-based seat inventory control problem clas$ 1 mve] 00 idnewy * 

can be formulated on a directed graph D=(V,A), III. Solving The System With Virtual Faxes And A 

where the set of vertices V represents the set of cities Leg-Based Method 

and the set of arcs A represents the set of flight leg^ If met hod to control 

the seat mventory control system » controls book- somehow accounting for the differ- 

mgsforai>artocularday.th« , A represent the set of all £tween long-haul and ahort-hful demand has 

fl.gh. legs occurring on that day, and it may include ~ virtual nesting methods (see. e.g., the fol- 

more than one fhght leg between some aty purs. A f publication> which g * incorporated herein by 

path or itmerary p h« a sequence of connecting night ^ travddemand and air- 

legs m the graph . D with an cmgmc,t y s(p) and a desti- management," Technical Report 

nation city t(p). If leg a is included u, mnerary p. then „ ragh 7 TraMp ?rt«tkm Laboratory, MaW 

•«p. In this context, otily .Unei.nes Mtufymg «>m>mun> * 1 ^ £ of Technology, Cambridg^ Mass., 

connecnon tunes constraint, ; »d 1 havmg "on-ne^giWe considering a particular flight kg, 

. ^"h T^T^JTp these methods discount the total fere paid by a long- 

itineraries ts denoted by P, and for each pcP, vp is estab- . . ^IT.*. J* *k-> 

. , , * . * . /j / •«., haul passenger using this leg by an estimate of the ats- 

bshed, which u the nominal revenue yield or tariff from - n , H ™ * f » * ' . . , , 

- I ■ r ♦ 1 *™ v . +lt 20 placement cost of his travel on the other legs of his 

fare class 1 for itinerary p travel from city s{p) to city r. TT . Al . . _ - " „;-*,,.i 

, N _ . , - - , itinerary. Using these discounted or virtual fares, virtual 

t(p). Booking limits S'» must be set for fare class 1 on " J * * 4 . . _ . TT V ; 

.t ° . • » a ■ a u nesting methods aggregate itinerary /fare class combi- 

ltinerary p so as to maximize total system revenue, sub- . * " , . 66 . » . , _ ' 4 . wt _, - M . . 

• - * *v * • * +v » «i nations with similar virtual fares into virtual fare buck- 

ject to the constraint that the total number of seats controlled by a conventional leg- 

authored for sale on each fl.ght leg a is exactly equal 25 ^ ^ n * ti ^ must £ 

tothecapac^ofthat e g C,^ turned border to map the numerous itinerary/fare 

the aircraft flying the leg (overbooking is considered in . . 4 u lf . / # 

the parent patem application incorporated herein by ^ combinauons mto different vntual fere buckets on 

reference). As a matter of notation, the superscript i is ea ~ l . 8 ' . . , . . . .-^ : , 

dropped whenever a total over all fare classes is £ken, 30 ^P 0 ^ .■*«* of P resent '™ n "°" * * e 

and hence- observation that it is unnecessary to use estimates of the 

displacement cost on the legs when computing virtual 
fares; the EMSR's themselves are the displacement 
A <±> costs. Hence, the virtual fare for travel on leg a along 

5p = / 2 j 5/ ^ itinerary p at fare class i is: 

where w is the number of fare classes or tariff code A (4) 

buckets. ^o-fp- * x & 

Since demand is stochastic, the total system revenue ^ a 
is actually a random variable, and so the objective of the 40 

present invention is to maximize its expected value R, jhi s is termed an EMSR-differential virtual fare since it 
which is just the sum of the expected revenue for all ^ computed by taking the difference between the total 
itinerary/fare class combinations. Writing this as an f are 15 t jj e EMSR's on the other legs. A leg-based 
equation gives: method that uses EMSR-differential virtual fares must 

45 be iterative since, as it recomputes the EMSR*s, it also 
4> (i) changes the virtual fares upon which they were based. 

* = ^ . ^ j V (*p) As was indicated, an iterated leg-based method using 

,=s virtual fares can be used to solve Eq. (3). However, the 

The capacity constraint for leg a can be written as: <ft EMSR-differential virtual fares of Eq^(4) will not en- 

50 sure this equivalence. In the unnested network-based 
method of the parent patent application Ser. No. 
I S, = Co, for Ji <*a ^ 07/630,261 filed Dec. 19, 1990 by Scot W. Hornick et 

F*? al. entitled "AIRLINE SEAT INVENTORY CON- 

a€ * TROL METHOD AND APPARATUS FOR COM- 

_ , 1 . c xr 55 PUTERIZED AIRLINE RESERVATION SYS- 

r£ S e o P ^ T c PP ! w 10 « i°\ 1 ?;i 1 TCMS,, » incorporated herein by reference, the number 
filed Dec. 19, 1990 by Scot W. Hornick et al. entitled ' n™/2i trt /for* nioec i ic 

-AIRLINE SEAT INVENTORY CONTROL of seats allocated to itinerary p fare class 1 is. 

METHOD AND APPARATUS FOR COMPUTER- 
IZED AIRLINE RESERVATION SYSTEMS", in- ^ , ^ . r £ f \ 
corporated herein by reference, it was shown that the ' Gp \ttp p \ 
solution to this constrained optimization problem is 

characterized by the system of equations: _ ^ 0l - , . . f t j * « 

J J ^ Let S'n t0 be the number of seats assigned to itinerary p 

fare class i travel on leg a by a leg-based method using 



(5) 



, t „ i / ^ . if ; \ ^ , „ A (3) 65 virtual fares vW The formula for S^ (using a distinct 

2 I O-'i I Xa//*' 1 = C 0 , for all atA . ? * , x . y 

KPi=\ p \btp p \ allocation method) is: 

S^^pO^v^) (6) 



pxPh 
aip 
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Solving this equation can be thought of as finding the 
Equating Eqs. (5) and (6), it can be shown that equiva- intersection of the graphs of two functions of an inde- 
lence is achieved when: pendent variable x: 



5 X e = x (8) 



J The first of these functions is simply a straight line 

^ B iXi through the origin with slope one. The second function 

is nonincreasing with x. Initially, when x is zero, all 
_ . . . 4 , . . . - ™„ virtual fares are admitted, and all possible terms appear 

<* T^/ s tc ™ cc * ^ EMSR-prorated virtual fare. FIG. m * e summation . th ^ ^ 

2 is a flow chart illustratog that when an iterated leg- 15 ^ fares are exceeded by x. 

based method using EMSR-prorated virtual fares con- ^ ^ ve$ rise tQ a desccn ding staircase behavior as 

verges, the seat allocations and EMSRs coincide with &hown in mG 3 Tvv0 Afferent cases can occur for the 

the optimal network-based solution, Le., the solution of intersection point: either it lies on a horizontal portion 

the system in Eq. (3). 0 f we staircase or it lies on a vertical portion of the 

20 

IV. Incorporating Nesting In The Optimization Model staircase. 

^ * * • The intersection point is found by proceeding up the 

In a previous section, a nested availability rule based staircase from right to left. As the staircase progress to 

on the sum of the EMSRs along a passenger itinerary subsequent virtual fares, first a check is made for a hori- 

was discussed. On the other hand, all of the optimiza- ^ zontal intersection with the diagonal line, and then the 

tion models discussed so far are based on, or internally next term is added, checking for a vertical intersection 

maintain, separate and distinct seat inventories for each (see FIG. 4). In the case of a vertical intersection, the 

itinerary/fare class combination. While these two ideas lowest included virtual fare class is said to be marginal 

are apparently contradictory, an unnested optimization and the EMSR is said to be fixed to the virtual fare. It 

model can be used quite effectively with a nested avail- 30 is almost certain that some of the demand from this 

ability rule. Nevertheless, some additional benefit can marginal fare class will have to be rejected, and the 

be derived from incorporating nesting into the optimi- EMSR of a fixed leg may have to be updated more 

zation model as well. frequently to prevent excessive booking of a marginal 

This can be done by developing a nested leg-based demand, 

optimization method and applying it to the EMSR- 35 As mentioned above this nested leg-based method is 

prorated virtual fare technique to obtain network-opti- extended to a network-based method through the mech- 

mal results. Consider a leg a with virtual fares: ™co°^ T° w ^ ?™*L ~ i f T. 

EMSR-difTerential virtual fares, the virtual fares on leg 

F i >p > a do not change with a change in Xa alone. However, 

4Q with EMSR- pro-rated virtual fares, changes in X a do 
Let E/denote the event that the demand for virtual fares have an immediate impact on the virtual fares cm leg a. 
P a and above exceeds the capacity Q, i.e., E/ occurs if Hence, the iterative structure of FIG 2 must be modi- 
more than ^passengers are willing to pay f,or more to f" to aUow the effect of this change to be reflected as 
travel on leg a. P(E f )=ir ( -is the probability of an occur- indicated in FICj. 4. 

rence of event E,\ Given that a seat will not be sold to 45 y implementation Of Common Initialization Routines 

a passenger who is unwilling to pay at least K (viewing ^ ar£ flow charts describing ^ operation of 

X„as a control parameter for the moment), the expected common ■ adtia ^ aAm routines m a computer program 

incremental value of a seat on the leg is: implementing each of the embodiments discussed infra. 

SO The following symbols are used in the flow charts 

// »/r n p \ an ^ ^ descriptions thereof: 

fj&l. L LE0 * 811 mde * to 8 le * of m itinerarv or P 81 "- 

2. IT1N is an itinerary (also termed "path"). 

where Eo=0 and — denotes complementation. How- ]■ l™:^^^^^ 6 «^ 

ever, this is just the EMSR. Thus, Ae correct value of 55 4 - ^E^P 0 * T 8 "^ T 

A. must satisfy: ofTeTeg^ l ^ * ""^^ ""^ 

5. MEAN(ITIN-F) is the mean of the demand for the 

K ~ fjk\f JP{ * n £,_I> 60 6. STDDEV(ITIN-F) is the standard deviation of the 

demand for the ITIN-F (i.t. t STDDEV(ITIN-F) 2 is the 
Noting that E M C E/by definition, this can be rewritten variance of the demand for the ITIN-F). 

7. FARE(ITIN-F) is the fare for an ITIN-F. 

8. CAPACITY(LEG) is the seating capacity of the 
65 LEG. 

= 2 fj {vi - »/_ 0 9. CURRENT-BUCKETS is a list of ITIN-Fs that 

use a LEG. Each ITIN-F containing the LEG is repre- 
sented by a bucket element. In this manner, all ITIN-Fs 
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using the LEG can be tracked so that seats can be allo- 
cated among the IT1N-F s. 

10. Each element of a bucket list contains the follow- 
ing variables: 

a. PATH-NUM is the path, i.e., ITIN, that gives rise 
to the bucket. 

b. FARE-IND is the fare class that gives rise to the 
bucket Combined with the PATH-NUM this pro- 
vides the ITIN-F. 

c. ELEMENT.MEAN is the mean of the demand for 
the LEG. 

d. ELEMENT.STDDEV is the standard deviation 
of the demand for the LEG. 

e. ELEMENT.TRUE-FARE is the true fare for the 
ITIN-F. 

f. ELEMENT. VIRT-F ARE is the virtual fare for 
the ITIN-F. 

g. ELEMENT.LAMBDA-OFFSET is the maximum 
LAMBDA value, i.e., EMSR, for which the 
bucket gets seats. 

h. ELEMENT.LAMBDA-OTHER is the summa- 
tion of the LAMBDA(LEG) values for the other 
LEGs on the ITIN. 

L ELEMENT.SEATS is the number of seats allo- 
cated to the ITIN-F. 

j. ELEMENT.EXPCFRESQ is a bucket-specific 
intermediate value. 

k. ELEMENT. SQR2PISBF is a bucket-specific con- 
stant 

FIG. 5 is a flow chart describing the logic of the 30 
GET INPUT routine. The GET INPUT routine inputs 
data consisting of: 

1. The names of the cities served by the airline. 

2. The leg information: 

a. night information; 

b. Origin; 

c. Destination; 

d. Capacity of the carriers; 

e. Distance; 

3. Itinerary Information: 

a. Flight number of the first leg; 

b. Origin; 

c. Destination; 

d. Number of stops; 

e. Flight number, origin and destination of each leg 45 
component; 

f. Fares for each fare class; 

g. The u.(ITIN-F), i.e., mean, and o-(ITIN-F), i.e., 
standard deviation, of demand for each ITIN-F. 

Because the present invention may be used with any 50 
number of airline reservation systems, the actual opera- 
tion of the GET INPUT depends on the specific format 
of the input supplied by the airline reservation system. 

FIG. 6 is a flow chart describing the logic of the . 
INIT (INITIALIZATION) routine in the present in- 55 
vention. The INIT routine initializes the global vari- • 
ables of the program, and calculates the starting 
LAMBDA (LEG) values using a leg-based mileage- 
prorated EMSR method. 

After the INIT routine starts, a first loop is executed 60 
once for each path, i.e., itinerary or ITIN, in the net- 
work. The total mileage of each ITIN is calculated. The 
first loop then terminates and a second loop is executed 
once for each LEG in the network. 

If CAPACITY(LEG) is nonzero, then a CON- 65 
STRUCT MILE PRORATED FARES routine is 
called for the LEG depending on the particular virtual 
fare method (the CONSTRUCT MILE PRORATED 



35 



40 



FARES routines differ in the details of the data struc- 
tures each uses). FIG. 7 is a flow chart describing the 
logic f the CONSTRUCT MILE PRORATED 
FARES routine in the unnested EMSR-prorated virtual 
fare method. FIG. 8 is a flow chart describing the logic 
of the CONSTRUCT MILE PRORATED FARES 
routine in the nested EMSR-prorated virtual fare 
method. FIG. 9 is a flow chart describing the logic of 
the CONSTRUCT MILE PRORATED FARES rou- 
tine in the nested EMSR-differential virtual fare 
method. The FARE-SUM and the BUCKET-COUNT 
is set to zero. A third loop is executed once for each 
element in the CURRENT-BUCKETS list The ELE- 
MENT.TRUE-FARE is summed in FARE-SUM and 
the BUCKET-COUNT is incremented by one. When 
the third loop terminates, the LAMBDA(LEG) is cal- 
culated by dividing the FARE-SUM by two times the 
BUCKET-COUNT. 

If CAPACITY(LEG) is zero, then the LAMBDA(- 
LEG) is set to a "huge value". 

The second loop terminates and the INIT routine 
terminates. 

FIG. 7 is a flow chart describing the logic of the 
CONSTRUCT MILE PRORATED FARES routine 
in the unnested EMSR-prorated virtual fare method. 
The CONSTRUCT MILE PRORATED FARES rou- 
tine initializes mileage prorated virtual fares to provide 
suitable initial EMSR's. 

The CONSTRUCT MILE PRORATED FARES 
routine has as its parameter the desired LEG in the 
network. After the routine starts, all previous buckets 
are de-allocated. A first loop is executed once for all 
paths, i.e., ITIN's, in the network containing the LEG. 
The PRORATION value is calculated by dividing the 
miles on the LEG by the miles for the ITIN. A second 
loop is executed for all fare classes in the ITIN. If 
MEAN(ITIN-F), STDDEV(ITIN-F) t and FARE(I- 
TIN-F) are all greater than zero, then LAMBDA- 
OFFSET is set to zero, TRUE-FARE and VIRT- 
FARE are set to the value of: 

(FARE<rnN-F)XPRORAT10N) 

LAMBDA-OFFSET is set to the value of: 
(VIRT-FARE)/2(erfc((— MEAN- 
(ITIN— F)/v2(STDDEV(rnN— F)))) 

and SQR2PISBF is set the value of: 

V2ff (STDDEV(ITIN - F))/CTRUE - FARE) 

A new element is created, LAMBDA-OTHER, 
LAMBDA-OFFSET, MEAN(ITIN-F), STDDEV(I- 
TIN-F), SQR2PISBF, TRUE-FARE, and VIRT- 
FARE are assigned thereto, and the new element is 
inserted into the CURRENT-BUCKETS list. The sec- 
ond and first loops terminate, and the CONSTRUCT 
MILE PRORATED FARES routine terminates. 

FIG. 8 is a flow chart describing the logic of the 
CONSTRUCT MILE PRORATED FARES routine 
in the nested EMSR-prorated virtual fare method. The 
CONSTRUCT MILE PRORATED FARES routine 
initializes mileage prorated virtual fares to provide suit- 
able initial EMSR's. 

The CONSTRUCT MILE PRORATED FARES 
routine has as its parameter the desired LEG in the 
network. After the routine starts, all previous buckets 
are de-allocated. A first loop is executed once for all 
paths, i.e., ITIN's, in the network containing the LEG. 
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The PRORATION value is calculated by dividing the 
miles on the LEG by the miles for the ITIN. A second 
loop is executed for all fare classes in the ITIN. . If 
MEAN(ITIN-F), STDDEV(ITIN-F), and FAREfl- 
TIN-F) are all greater than zero, then TRUE-FARE 
and VIRT-FARE are set to the value of: 

(FARE(rnN-F)XPRORATION) 

A new element is created, LAMBDA-OFFSET, 
MEAN(ITIN-F), STDDEV(mN-F) l TRUE-FARE, 
and VIRT-FARE are assigned thereto, and the new 
element is inserted into the CURRENT-BUCKETS 
1st. The second and first loops terminate, and the CON- 
STRUCT MILE PRORATED FARES routine termi- 
nates. 

FIG. 9 is a flow chart describing the logic of the 
CONSTRUCT MILE PRORATED FARES routine 
in the nested EMSR-differential virtual fare method. 
The CONSTRUCT MILE PRORATED FARES rou- 
tine initializes mileage prorated virtual fares to provide 
suitable initial EMSR's. 

The CONSTRUCT MILE PRORATED FARES 
routine has as its parameter the desired LEG in the 
network. After the routine starts, all previous buckets 
are de-allocated. A first loop is executed once for all 
paths, i.e., ITIN's, in the network containing the LEG. 
The PRORATION value is calculated by dividing the 
miles on the LEG by the miles. for the ITIN. A second 
loop is executed for all fare classes in the ITIN. If 
MEAN(ITIN-F), STDDEV(ITIN-F), and FARE(I- 
TIN-F) are all greater than zero, then TRUE-FARE 
and VIRT-FARE are set to the value of; 

(FAREtmN -DXPRORATION) 

A new element is created, LAMBDA-OFFSET, 
MEAN(ITIN-F), STDDEV(ITIN-F), TRUE-FARE, 
and VIRT-FARE are assigned thereto, and the new 
element is inserted into the CURRENT-BUCKETS 
list. The second and first loops terminate, and the CON- 
STRUCT MILE PRORATED FARES routine termi- 
nates. 

VI. Implementation Of Unnested EMSR-Prorated 
Virtual Fare 

FIGS: 10-16 are flow charts describing the operation 
of a number of routines of a computer program imple- 
menting the Unnested EMSR-Prorated Virtual Fare ^ 
Method. For each flight leg in the network which still 
has residual capacity (i.e., unsold seats), an EMSR- 
prorated virtual fare is computed for each itinerary /fare 
class that contains the leg using previously calculated 
EMSR's. Based on these virtual fares, the new EMSR 55 
for the leg is calculated by applying Newton's method 
to the capacity constraint equation for the leg (which 
ensures that the number of seats assigned to the various 
virtual fare classes on the leg is equal to the residual 
capacity of the flight). If NEWTON'S method fails to 60 
converge, then a binary search is used. Since each step 
of Newton's method (or binary search) changes the 
EMSR of the current leg, the virtual fares must be 
updated at each step. Once Newton's method (or binary 
search) converges, then the next leg is processed. The 65 
loop terminates when a pass through all legs in the 
network results in no significant change (by more than 
a penny) in any EMSR. 
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The following symbols are used in the flow charts 
and the descriptions thereof: 

1. LEG is an index to a leg of an itinerary or path. 

2. ITIN is an itinerary (also termed "path**). 

3. ITIN-F is an itinerary/fare class combination. 

4. LAMBDA(LEG) is the expected marginal seat 
revenue (EMSR) generated by increasing the capacity 
of the leg by 1 seat. 

5. MEAN(ITIN-F) is the mean of the demand for the 
ITIN-F. 

6. STDDEV(ITIN-F) is the standard deviation of the 
demand for the ITIN-F (i.e. ( STDDEVflTIN-F) 2 is the 
variance of the demand for the ITIN-F). 

7. FARE(ITIN-F) is the fare for an ITIN-F. 

8. CAPACITY(LEG) is the mean of the demand for 
the ITIN-F. 

9. DELTA is the change in the EMSR, i.e., the 
change in LAMBDA (LEG). 

10. EPSILON is a tolerance value. 

11. CURRENT-BUCKETS is a list of ITTN-Fs that 
use a LEG. Each ITIN-F containing the LEG is repre- 
sented by a bucket element. In this manner, all lTlN-Fs 
using the LEG can be tracked so that seats can be allo- 
cated among the ITIN-Fs. 

1 1. FIXED-BUCKETS is a list of elements that have 
been 'Tixed", Le., wherein the virtual fare is approxi- 
mately equal to the LAMBDA(LEG) value. 

12. Each element of a bucket list contains the follow- 
ing variables: 

a. PATH-NUM is the path, i.e., ITIN, that gives rise 
to the bucket. 

b. FARE-IND is the fare class that gives rise to the 
bucket Combined with the PATH-NUM this pro- 
vides the ITIN-F. 

c. ELEMENT.MEAN is the mean of the demand for 
the LEG. 

d. ELEMENT.STDDEV is the standard deviation 
of the demand for the LEG. 

e. ELEMENT.TRUE-FARE is the true fare for the 
ITIN-F. 

f ELEMENT. VIRT-FARE is the virtual fare for 
the ITIN-F. 

g. ELEMENT.LAMBDA-OFFSET is the maximum 
LAMBDA value, i.e., EMSR, for which the 
bucket gets seats. This value is required for those 
demand models, e.g., the Gaussian demand model, 
that anomalously assign non-zero probability to 
negative demand. Demand models, e.g., the incom- 
plete gamma distribution, that do not assign non- 
zero probability to negative demand will not use 
this value, e.g., ELEMENT.LAMBDA-OFFSET- 
=ELEMENT. VIRT-FARE. 

h. ELEMENT.LAMBDA-OTHER is the summa- 
tion of the LAMBDA(LEG) values for the other 
LEGs on the ITIN. 

i. ELEMENT. SEATS is the number of seats allo- 
cated to the ITIN-F. 

j. ELEMENT. EXPCFRESQ is a bucket-specific 
intermediate value. 

k. ELEMENT.SQR2PISBF is a bucket-specific con- 
stant. 

FIG. 10 is a flow chart describing the MAIN routine 
in the Unnested EMSR-Prorated Virtual Fare Method. 
At the start of the MAIN routine, the GET INPUT and 
INIT routines of FIGS. 6 and 7 respectively are called. 
The variable DONE is set to the value 1. A first loop is 
performed for each leg in the network. If CAPACITY(- 
LEG) is greater than zero, then the CONSTRUCT 
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VIRTUAL FARES routine is called for the leg. The A FIXED-BUCKETS list is initialized with 0 elements 
CALC LAMBDA routine is called and if the return on the list. A second loop is performed for every de- 
value therefrom is 0, then DONE is set to 0. If the ment in the CURRENT-BUCKETS list. LAMBDA- 
CAPACITY(LEG) is zero, then LAMBDA (LEG) is OFFSET is set to the value of ELEMENT.LAMBDA- 
set to a large initial value. When the first loop termi- 5 OFFSET. If LAMBDA -OFFSET is less than the result 
nates, after examining each leg in the network, the of LAMBDA (LEG) minus LAMBDA-RESOLU- 
DONE variable is examined. If DONE is 0, then the TION, then ELEMENT.SEAT is set to 0, ELE- 
loop is performed again; otherwise, the MAIN routine MENT.EXPCFRESQ is set 0, and the second loop 
terminates. terminates. If LAMBDA-OFFSET is greater than or 

FIGS. 11 A and 11B describe the CALC LAMBDA 10 equal to the result of LAMBDA (LEG) minus LAMB- 
routine. The CALC LAMBDA routine is called with a DA-RESOLUTION and LAMBDA-OFFSET is less 
LEG parameter and calculates the LAMBDA (LEG) than or equal to the result of LAMBDA (LEG) phis 
value. If the CURRENT-BUCKETS list is empty, then LAMBDA-RESOLUTION, then ELEMENT.MEAN 
the aggregated demand for the leg is far less than the is added to TOTAL-MEAN; ELEMENT. STDDEV is 
residual capacity of the leg, so LAMBDA (LEG) is set IS added to TOTAL-STDDEV; a new element is alio- 
to 0 and a true value is returned to the calling procc- cated and inserted into the FIXED-BUCKETS list; 
dure. If the CURRENT-BUCKETS list has elements, ELEMENT.EXPCFRESQ is set to 0, and the second 
then the CALC LIMITS routine is called to calculate loop terminates. If LAMBDA-OFFSET is greater than 
the capacity slack, which is stored in the variable G. If the result of LAMBDA (LEG) plus LAMBDA-RESO- 
G is positive or equal to 0, then the upper bound ULL 20 LUTION, then the local variable DISPLACE is set to 
is set to the value of LAMBDA(LEG) and the lower the value returned by the CFRE routine, ELEMENT- 
bound LLL is set to 0. If the variable G is negative, then .SEATS is set to the result of ELEMENT.MEAN plus 
ULL and LLL are both set to the LAMBDA (LEG) the result of the square root of 2 multiplied by ELE- 
value. A first loop is performed for every element in the MENT.STDDEV multiplied by DISPLACE, G has 
CURRENT-BUCKETS list If ELEMENT. VIRT- 25 subtracted from it ELEMENT. SEATS, ELEMENT- 
FARE is greater than ULL, then ULL is set to the .EXPCFRESQ is set to the value of the exponential 
value of ELEMENT. VIRT-FARE. Thus, ULL is set value of DISPLACE squared, and the second loop 
to the maximum virtual fare. When the first loop termi- terminates. After the second loop terminates, then if the 
nates, if the absolute value of the capacity slack G is less variable G is greater than 0, then DISPLACE is set to 
than the value of CAP-TOLER, then the variable 30 the result of G minus TOTAL-MEAN, the result 
CAP-WAS-OK is set to true, otherwise it is set to false, thereof divided by TOTAL-STDDEV. If DISPLACE 
and the routine terminates. is greater than —2.5, then DISPLACE is set to —2.5. A 

FIG. 12 is a flow chart describing the CALC LIM- third loop is performed for all elements in the FIXED- 
ITS routine in the Unnested EMSR-Prorated Virtual BUCKETS list The value of ELEMENT.SEATS is 
Fare Method. This routine is called with a LEG param- 35 set to the result of ELEMENT.MEAN plus the result 
eter and calculates the residual capacity for the leg. It of ELEMENT. STDDEV multiplied by DISPLACE, 
also calculates the booking limits for each itinerary/fare The value of G has subtracted from it the value of ELE- 
class combination. On each itinerary/fare class combi- MENT. SEATS. The first element of the FIXED- 
nation, a number of different special situations can oc- BUCKETS list is then deleted and the third loop termi- 
cur: (1) the LAMBDA (LEG) may be less than EPSI- 40 nates. On the other hand, if the variable G is less than or 
LON which means that the aggregated demand on the equal to 0 after termination of the second loop, then a 
leg is far below the residual capacity and therefore fourth loop is performed for every element in the FIX- 
every request can be satisfied; (2) the LAMBDA (LEG) ED-BUCKETS list. The value of ELEMENT.SEATS 
may be greater than the ELEMENTXAMBDA- is set to 0 and the element is deleted from the FIXED- 
OFFSET for the itinerary/fare class combination, in 45 BUCKETS list. 

which case the booking limit is set to 0; and (3) the FIG. 13 is a flow chart describing the CONSTRUCT 
LAMBDA (LEG) may be close to the ELEMENT- VIRTUAL FARES routine in the Unnested EMSR- 
.LAMBDA-OFFSET for the itinerary/fare class com- Prorated Virtual Fare Method. This routine constructs 
bination, in which case the itinerary/fare class is stored EMSR-prorated fares for each bucket element For 
in a FIXED-BUCKET list. 50 each itinerary using the leg, the ELEMENT.LAMB- 

At the start of the CALC LIMITS routine, the vari- DA-OTHER variable is determined by subtracting the 
able G stores the value of CAPACITY (LEG). If LAMBDA(LEG) from the ELEMENT.LAMBDA- 
LAMBDA (LEG) is less than EPSILON, then a first SUM of the itinerary. Then, for each itmerary/fare 
branch occurs. The local variables TOTAL-MEAN class combination, the ELEMENT. VIRT-FARE is 
and TOTAL-STDDEV are set to 0. A first loop is 55 calculated by multiplying the ELEMENT.TRUE- 
performed for every element in the CURRENT- FARE by the LAMBDA(LEG) and dividing by the 
BUCKETS list. If ELEMENT. VIRT-FARE is greater LAMBDA-SUM. If the ELEMENT. VIRT-FARE is 
than or equal to EPSILON, then ELEMENT.MEAN greater than 0, then a CURRENT-BUCKETS list ele- 
is added to TOTAL-MEAN and the square of ELE- ment is created and linked to the existing CURRENT- 
MENT.STDDEV is added to TOTAL-STDDEV. 60 BUCKETS list. 

When the first loop terminates, the square root of the The CONSTRUCT VIRTUAL FARES routine is 
TOTAL-STDDEV is calculated and stored therein. called with a LEG parameter and upon starting, the 
The TOTAL-MEAN is added to three times TOTAL- memory of the previous buckets is de-allocated. A first 
STDDEV and subtracted from G. If G is greater than loop is performed for all paths containing the leg. The 
0, then G is set to 0. The routine then terminates. If 65 value of ELEMENT.LAMBDA-OTHER is set to the 
LAMBDA (LEG) is greater than or equal to EPSI- value of a negative LAMBDA (LEG). A second loop is 
LON, then a second branch occurs. The local variables performed for every leg of the path. The LAMBDA 
TOTAL-MEAN and TOTAL-STDDEV are set to 0. (LEG) value is added to ELEMENT.LAMBDA- 
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OTHER. Upon termination of the second loop, a third than the EPSILON tolerance value, and the absolute 

loop is performed for each fare of the path. If MEAN(I- value of G is less than the EPSILON tolerance value 

TIN-FX STDDEV(ITIN-F), and FARE(ITIN-F) are (558). The LAMBDA(LEG) is calculated as (560): 
all greater than 0, then a new element is allocated and 

the following actions are performed therefor: the value 5 ULL , uj_ 

of ELEMENT.TRUE-FARE is set to the value of MLEG)= f 

FARE(ITIN-F); the value of ELEMENT. VIRT- 

FARE is set to the result of FARE(ITIN-F) multiplied if g, which is the returned value from the routine CAL- 

by LAMBDA(LEG) and divided by the result of CULATE LIMITS, is less than 0 (562), then ULL is set 

LAMBDA(LEG) plus ELEMENT.LAMBDA- 10 t0 the \(LEG) value (564). Otherwise (562), if G is 

OTHER; the value of ELEMENT.LAMBDA- ^ or to 0 (562)( then LLL is set to the 

OFFSET is set to the result of: X(LEG) value (566). The first loop terminates when 

(element. vtrt-fare)/2 complete (558), and the BINARY routine then termi- 

(erfc(-MEAN(mN-F)/fy2) nates (568). 

(STDDEV(rtiN-F)))) V II Implementation Of Nested EMSR-Prorated 

and the ELEMENT.SQR2PISBF is set to the result of: Virtual Fare 

FIGS. 17-21 are flow charts describing the operation 

(V £mnFv*TtN Fw/Ti fmf.nt true ^ of a nttmber of routines of a computer program in the 

(s™EV(rnN-F)V(ELEMENT.TRUE- Nested ^^jp^^ virtual Fare Method. For each 

flight leg in the network which still has residual capac- 
FIG. 14 is a flow chart describing the DELFUNC ity, an EMSR-prorated virtual fare is computed for 
routine. This routine is called with a LEG parameter each itinerary/fare class that contains the leg using 
and calculates the following value for the buckets on a previously calculated EMSR's. The itinerary/fare 
given leg: classes are then sorted in order of descending virtual 

fare. Next, by processing this sorted list of virtual fares 
(V2^) <r/(ELEM ent.true-fare) one-by-one, a trace is made upward to the left along the 

cxpWcM^LEMENT.viRT-FARE))^) staircase graph of FIG. 3 to find its intersection with the 

. t » * , /DTNA , T , . # . . u . _ , ft straight line through the origin. This intersection point 

In a simple LAMBDA (LEG) calculation, there s no 30 defm ^ ^ £! * SR for ^ , but ^ce EMSR . 
distinction between true fares and virtual fares, but this £ of this leg, 

TSha A h Frf ^ they must be rec^culatedand re-sorted, and the intef- 

™M £ ™ 3 P £ mSuNC routine, a local van- ^ for the leg must be recomputed. This pro- 

able SUM is set to 0. A first loop is performed for every 35 «« Repeated until the EMSR on this leg converges; 
element in the CURRENT-BUCKETS list. If ELE- then the next leg is processed. The loop terminates 
MENT.EXPCFRESQ is not 0, then the value of ELE- wh * n a P* 55 though all legs in the network results in no 
MENT.SQR2P1SBF multiplied by ELEMENT- significant change (by more than a penny) in any 
.EXPCFRESQ and the result thereof added to SUM. EMSR. 

The value of SUM is returned to the calling routine 40 ^ fol,owin g symbols are used in the flow charts 
when DELFUNC terminates. the descriptions thereof: 

FIG. 15 is a flow chart describing the UPDATE I. LEG is an index to a leg of an itinerary or path. 
VIRTUAL FARES routine in the Unnested EMSR- 2. ITIN is an itinerary (also termed "path"). 
Prorated Virtual Fare Method. This routine is called 3. ITIN-F is an itinerary/fare class combination, 
with a LEG parameter and updates the virtual fares 45 4 - CAPACITY(LEG) is the seating capacity of the 
using the new LAMBDA (LEG) value. The virtual LEG. 

fares are calculated by multiplying ELEMENT.TRUE- 5. LAMBDA(LEG) is the expected marginal seat 
FARE by the LAMBDA (LEG) and dividing by the revenue (EMSR) generated by increasing the capacity 
LAMBDA-SUM. of the leg by 1 seat. 

At the start of the UPDATE VIRTUAL FARES 50 6. MEAN(ITIN-F) is the mean of the demand for the 
routine, a first loop is performed for every element in ITIN-F. 

the CURRENT-BUCKETS list The ELEMENT- 7. STDDEV(ITIN-F) is the standard deviation of the 
.VIRT-FARE is set to the result of ELEMENT.- demand for the ITIN-F (i.e., STDDEVflTIN-F) 2 is the 
TRUE-FARE multiplied by LAMBDA(LEG) and variance of the demand for the ITIN-F). 
divided by the result of LAMBDA(LEG) plus ELE- 55 8. FARE(ITIN-F) is the fare for an ITIN-F. 
MENT.LAMBDA-OTHER. The ELEMENT- 9. DELTA is the change in the EMSR, it, 
.LAMBDA-OFFSET is set to the result of: LAMBDA (LEG). 

10. EPSILON is a tolerance value. 
^nSIpS!^' 1 l > FIXED(LEG) is a flag that indicates whether the 

(El^KTS^EV)) 60 LEG has been "fixed", i.e., wherein some virtual fare is 

approximately equal to the LAMBDA(LEG) value. 
After the first loop terminates, the routine terminates, 12. CURRENT-BUCKETS is a list of ITIN-Fs that 

FIG. 16 is a flow chart describing the BINARY rou- use the LEG. Each ITIN-F containing the LEG is 
tine. This routine is called with a LEG parameter and represented by a bucket element. In this manner, all 
uses a binary search to calculate LAMBDA(LEG) for a 65 ITIN-Fs using the LEG can be tracked so that seats 
given leg, when the other methods have failed. After can be allocated among the ITIN-Fs. 
the BINARY routine starts (556), a first loop is exe- 13- Each element of a bucket list contains the follow- 
cuted until the difference between ULL and LLL is less ing variables: 
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a. PATH-NUM is the path, i.e., ITIN, that gives rise TIN-F) are all greater than 0, then the LAMBDA-SUM 

to the bucket * examined to see if it is greater than the EPSILON 

b FARE-IND is the fare class that gives rise to the value. If it is greater, then the ELEMENT. V1RT- 
* buckct FARE is set to the value of ELEMENT.TRUE-FARE 

c ELEMENT.MEAN is the mean for the bucket. 5 multiplied by the LAMBDA (LEG) and divided by the 
d ELEMENT. STDDEV is the standard deviation LAMBDA-SUM, If the LAMBDA-SUM is less than 

for the bucket. the EPSILON value, then the ELEMENT. VTRT- 

e ELEMENT.TRUE-FARE is the true fare for the FARE is set to the value of ELEMENT.TRUE- 

corresponding fare class/itinerary combination. FARE. If the ELEMENT. VIRT-F ARE is greater than 
f ELEMENT. V IRT-F ARE is the virtual fare for 10 0, then memory is allocated for another element in the 

the bucket. CURRENT-BUCKET list and the element is inserted 

g. ELEMENT. LAMBDA-OTHER is the summa- therein. The third loop and first loops terminate and the 

tion of LAMBDA(LEG) on other legs in the itin- routine terminates. 

erary, FIG. 20 is a flow chart describing the FIND INTER- 

FIG. 17 is a flow chart describing the MAIN routine 15 SECTION routine in the Nested EMSR-Prorated Vir- 
in the Nested EMSR-Prorated Virtual Fare Method. At tual Fare Method. This routine is called with a LEG 
the start of the MAIN routine, the GET INPUT and parameter. At the start, local variables NEW-LEVEL, 
INIT routines are called. The variable DONE is set to HIGHER-REJ. CUM-MEAN, AND CUM-VAR are 
the value 1. A loop is performed for each leg in the set to 0. A first loop is performed for every element in 
network. If the leg has residual capacity, then the CON- 20 the CURRENT-BUCKETS list so long as ELE- 
STRUCT VIRTUAL FARES routine is called for the MENT.VIRT-FARE for each elements is greater than 
leg. The CALC LAMBDA routine is called and if the NEW-LEVEL. Each ELEMENT.MEAN is added to 
return value therefrom is 0, then the DONE variable is CUM-MEAN. Each ELEMENT.STDDEV is squared 
set to 0. If the leg does not have residual capacity, then and added to CUM-VAR. A value for the variable 
LAMBDA (LEG) is set to infinity, which is referred to 25 proB is calculated as: 
as HUGE-VAL. When the first loop terminates, after 
examining each leg in the network, the DONE variable pRQB = 
is examined. If the DONE variable is 0, the loop is 

performed again; otherwise, the MAIN routine termi- / fCAPACrryfLEcm - rcuM-MEAN) >^ 

nates. ^ 30 **[t( J U , " * J J 

FIG. 18 is a flow chart describing the CALC ^ V> N2(CUM-var) // 

LAMBDA routine in the Nested EMSR-Prorated Vir- 

tual Fare Method. The CALC LAMBDA routine cal- The variable PROB could be calculated differently if an 
culates the LAMBDA (LEG) value. The routine is alternate demand distribution model is used, 
called with a LEG parameter. If the CURRENT- 35 ELEMENT. VIRT-FARE is multiplied by the result 
BUC1CETS list is empty, then LAMBDA (LEG) is set of PROB minus HIGHER-REJ, and the result added to 
to 0 and a value of 1 is returned to the calling procedure. NEW-LEVEL. Then, HIGHER-REJ is set equal to 
Otherwise, LAMBDA (LEG) is temporarily stored in PROB. Upon termination of the first loop, the ELE- 
the variable OLDL. The SORT VIRTUAL FARES MENT.VIRT-FARE of the last dement processed m 
routine is called to sort the virtual fares for the leg in 40 the first loop is compared to NEW-LEVEL. If ELE- 
ascending order (using any known sort technique). The MENT.VIRT-FARE of the last element is less than 
LAMBDA (LEG) is stored is stored in the variable NEW-LEVEL, then NEW-LEVEL is set to the value 
LASTL and a new LAMBDA (LEG) value is calcu- of ELEMENT. VIRT-FARE of the last element and 
lated by the FIND INTERSECTION routine. If the FIXED(LEG) is set to a value of 1. If the ELE- 
LAMBDA (LEG) is less than the EPSILON value, 45 MENT.VIRT-FARE of the last dement is greater tlian 
then LAMBDA (LEG) is set to 0. The UPDATE VIR- or equal to NEW-LEVEL, then FIXED(LEG) is set to 
TUAL FARES routine is called for the leg. The value a value of 0. The NEW-LEVEL value is then returned 
of LASTL is subtracted from LAMBDA (LEG), and if to the calling routine. . 
the absolute value thereof is greater than or equal to FIG. 21 is a flow chart describmg the UPDATE 
LAMBDA-RESOLUTION, and if LAMBDA (LEG) 50 VIRTUAL FARES routine in the Nested EM SR- 
is greater than EPSILON, then a value of 1 is returned Prorated Virtual Fare Method. This routine is called 
to the calling procedure. Otherwise, the LAMBDA with a LEG parameter. A local variable PREV-FARE 
(LEG) is calculated again. « set to infinity, which is referred to as HUGE-VAL^ 

FIG. 19 is a flow chart describing the CONSTRUCT first loop is performed for all elements in the CUR- 
VIRTUAL FARES routine in the Nested EMSR- 55 RENT-BUCKETS list. For ^^^^J;^' 
Prorated Virtual Fare Method. This routine constructs DA(LEG) is added to ELEMENT.LAMBDA- 
EMSR-ororated fares for each bucket element This OTHER, and the result therefrom is stored in LAMB- 
routine is called with a LEG parameter. First, the rou- . DA-SUM. If LAMBDA-SUM is greater than or equal 
tine de-allocates previous bucket elements. A first loop to EPSILON, then ELEMENT. VIRT-FARE is set to 
is performed for all paths containing the leg. The value 60 the value of the ELEMENT.TRIJE-FARE multiplied 
of the LAMBDA-SUM variable is set to zero. A second by LAMBDA (LEG) and divided by LAMBDA-SUM. 
loop is performed for each leg in the path. The If LAMBDA-SUM is less than EPSILON, then ELE- 
LAMBDA (LEG) values for each leg in the path are MENT.VIRT-FARE is set to the value : of ELE- 
added to LAMBDA-SUM. After the second loop ter- MENT.TRUE-FARE. If ELEMENT. VIRT-FARE is 
minates, LAMBDA-OTHER is set to the value of 65 greater than the PREV-FARE, .then the element b 
LAMBDA-SUM minus LAMBDA (LEG). A third advanced through the CURREOT-BUCKETS list 
loop is performed for each fare of the path. If the until an ordering of decreasing irv^«BT c^P 
MEAN(ITIN-F) ( STDDEV(I TIN-F), and FARE(I- FARES is reestablished. If ELEMENT. VIRT-FARE 
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is less than or equal to PREV-FARE, then PREV- 
FARE is set to the value of ELEMENT. VIRT-FARE. 

VIII. Implementation Of Nested EMSR-Differential 

Virtual Fare 5 

FIGS. 22-25 are flow charts describing the operation 
of a number of routines of a computer program imple- 
menting the Nested EMSR-DifTerential Virtual Fare 
Method. For each flight leg in the network which still 
has residual capacity, an EMSR-difTerential virtual fere 10 
is computed for each itinerary /fare class that contains 
the leg using previously calculated EMSR's. The 
itinerary/fare classes are then sorted in order of de- 
scending virtual fare. Next, by processing this sorted list 
of virtual fares one-by-one, a trace is made upward to 15 
the left along the staircase graph of FIG. 3 to find its 
intersection with the straight line through the origin. 
This intersection point defines the new EMSR for the 
leg. The next leg is then processed. The loop terminates 
when a pass through all legs in the network results in no 20 
significant change (by more than a penny) in any 
EMSR. 

The following symbols are used in the flow charts 
and the descriptions thereof: 

1. LEG is an index to a leg of an itinerary or path. 25 

2. ITIN is an itinerary (also termed "path"). 
3; ITIN-F is an itinerary /fare class combination. 

4. CAP A CITY (LEG) is the mean of the demand for 
the ITIN-F. 

5. LAMBDA(LEG) is the expected marginal seat 30 
revenue (EMSR) generated by increasing the capacity 
of the leg by 1 seat. 

6. FIXED(LEG) is a flag that indicates whether the 
LEG has been 'Tixed", i.e., wherein some virtual fare is 
approximately equal to the LAMBDA(LEG) value. 35 

7. MEAN(ITIN-F) is the mean of the demand for the 
ITIN-F. 

8. STDDEV(ITIN-F) is the standard deviation of the 
demand for the ITIN-F (i.e., STDDEV(ITIN-F)2is the 
variance of the demand for the ITIN-F). 40 

9. FARE(ITIN-F) is the fare for an ITIN-F. 

10. DELTA is the change in the EMSR, i.e., 
LAMBDA (LEG). 

1 1. EPSILON is a tolerance value. 

12. CURRENT-BUCKETS is a list of ITIN-Ps that 45 
use a LEG. Each ITIN-F containing the LEG is repre- 
sented by a bucket element In this manner, all ITIN-Fs 
using the LEG can be tracked so that seats can be allo- 
cated among the ITIN-F's. 

13. Each element of a bucket list contains the follow- 50 
ing variables: 

a. PATH-NUM is the path index that gives rise to the 
bucket. 

b. FARE-IND is the fare class index that gives rise to 
the bucket. 55 

c. ELEMENT.MEAN is the mean of the demand for 
the ITIN-F. 

d. ELEMENT.STDDEV is the standard deviation 
of the demand for the ITIN-F. 

e. ELEMENT.TRUE-FARE is the true fare for the 60 
corresponding fare class/itinerary combination. 

f. ELEMENT. VIRT-FARE is the virtual fare for 
the bucket 

FIG. 22 is a flow chart describing the MAIN routine 
in the Nested EMSR-Differential Virtual Fare Method. 65 
At the start of the MAIN routine, the GET INPUT and 
I KIT routines are called. The variable DONE is set to 
the value 1. A first loop is performed for each leg in the 



network. If the leg has residual capa ci ty, then the CON- 
STRUCT VIRTUAL FARES routine is called for the 
leg. The CALC LAMBDA routine is called and the 
return value therefrom is saved. If the return value is 0, 
then DONE is set to 0. If the leg does not have residual 
capacity, then LAMBDA (LEG) is set to infinity, 
which is referred to as HUGE-VAL. When the first 
loop terminates, after examining each leg in the net- 
work, the DONE variable is examined. If DONE is 0, 
then the loop is performed again; otherwise, the MAIN 
routine terminates. 

FIG. 23 is a flow chart describing the CALC 
LAMBDA routine in the Nested EMSR-Differential 
Virtual Fare Method. The CALC LAMBDA routine is 
called with a LEG parameter and calculates the 
LAMBDA (LEG) value. At the start of the routine, if 
the CURRENT-BUCKETS list is empty, then 
LAMBDA (LEG) is set to 0 and a true value is returned 
to the calling routine. Otherwise, the variable OLDL is 
set to the value of LAMBDA (LEG). The SORT VIR- 
TUAL FARE routine is called for the leg. The FIND 
INTERSECTION routine is called for the leg and the 
value returned therefrom is stored in the LAMBDA 
(LEG). If the absolute value of the results of subtracting 
OLDL from LAMBDA (LEG) is less than EPSILON, 
then a true value is returned to the calling routine; oth- 
erwise a false value is returned. 

FIG. 24 is a flow chart describing the CONSTRUCT 
VIRTUAL FARES routine in the Nested EMSR-Dif- 
ferential Virtual Fare Method. This routine is called 
with a LEG parameter and constructs EMSR-prorated 
fares for each bucket element. For each itinerary using 
the leg, the ELEMENT.LAMBDA-OTHER variable 
is determined by subtracting the LAMBDA(LEG) 
from the ELEMENT. LAMBDA-SUM of the itinerary. 
Then, for each itinerary/fare class combination, the 
ELEMENT. VIRT-FARE is calculated by subtracting 
ELEMENT.LAMBDA-OTHER from the ELE- 
MENT.TRUE-FARE. If the ELEMENT. VIRT- 
FARE is greater than 0, then a CURRENT-BUCK- 
ETS list element is created and linked to the existing 
CURRENT-BUCKETS list. 

The CONSTRUCT VIRTUAL FARES routine is 
called with a LEG parameter and constructs the ELE- 
MENT.VIRT-FARE values. At the start of the rou- 
tine, the memory of previous buckets is deallocated. A 
first loop is performed for all paths containing the leg. 
The variable LAMBDA-OTHER is set to the negative 
value of LAMBDA (LEG). A second loop is per- 
formed for all legs in the path. For each leg in the path, 
the LAMBDA (LEG) value is added to the LAMB- 
DA-OTHER value. Upon termination of the second 
loop, a third loop is performed for each fare in the path. 
If the MEAN(inN-F), STDDEV(TTTN-F), and 
FARE(ITIN-F) are all greater than 0, then ELE- 
MENT.TRUE-FARE is set to the value of FARE(I- 
TIN-F) and ELEMENT. VIRT-FARE is set to the 
result of FARE(ITIN-F) minus LAMBDA-OTHER. If 
ELEMENT. VIRT-FARE is greater than 0, then a new 
element is created for the CURRENT-BUCKETS list 
and inserted therein. 

FIG. 25 is a flow chart describing the FIND INTER- 
SECTION routine in the Nested EMSR-DifTerential 
Virtual Fare Method. This routine is called with a LEG 
parameter. A number of local variables are initialized to 
0, including NEW-LEVEL, HIGHER-REJ, CUM- 
MEAN, and CUM-VAR. A first loop is performed for 
all elements in the CURRENT-BUCKETS list while 
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each ELEMENT. VIRT-FARE is greater than the 
value of NEW-LEVEL. The ELEMENT. MEAN is 
accumulated in the variable CUM-MEAN and the 
ELEMENT. STDDE V is squared and added to CUM- 
VAR. The variable PROB is calculated as: 

Jerfc((CAPACnT(LEG)--(CUM-MEAN)VV2 
(CUM -VAR)) 

The value of ELEMENT. VIRT-FARE is multiplied 
by the result of PROB minus HIGHER-REJ and the 



method is applied to the virtual fares to obtain network- 
optimal results. 

The foregoing descriptions of the preferred embodi- 
ments of the invention have been presented for the 

5 purposes of illustration and description. These preferred 
embodiments are not intended to be exhaustive nor to 
limit the invention to the precise forms disclosed. Many 
modifications and variations are possible in light of the 
above teaching. It is intended that the scope of the 

10 invention be limited not by this detailed description, but 
rather by the claims appended thereto. 

, TABLE 1 

Comparison Of Seat ADocation Methods 





Optimal 


Demand 


Number Of 


Computational 


Method 


Basis 


Characteristics 


Variables 


Complexity 


Ug-based EMSR 


L*g 


Stochastic 


Small 


Linear 


Virtual-Nesting EMSR 


Leg 


Stochastic 


Small 


Linear 


Deterministic LP 


Network 


Deterministic 


Large 


Large Polynomial 


Probabilistic LP 


Network 


Stochastic 


Very Large 


Exponential 


Network-Based EMSR 


Network 


Stochastic 


Small 


Small Polynomial 



result thereof added to NEW-LEVEL. The value of 
HIGHER-REJ is set to the value of PROB. Upon ter- 
mination of the first loop, if the last ELEMENT. VIRT- 25 
FARE is less than NEW-LEVEL, then NEW-LEVEL 
is set to the value of ELEMENT. VERT-FARE and 
FIXED(LEG) is set to 1. If the last ELEMENT. VIRT- 
FARE is less than NEW-LEVEL, then FIXED(LEG) 
is set to 0. The value of NEW-LEVEL is returned to 30 
the calling routine. 

IX. Conclusion 

This concludes the description of the three preferred 
embodiments of the present invention. The following 35 
paragraphs describe some alternative embodiments of 
the invention. 

Any number of other yield management solutions 
could be substituted for the airline seat inventory con- 
trol system described herein. Instead of using seats, 40 
itinerary/fare classes, and flight legs, the invention 
could be formulated in terms of resources, demand 
categories, and resource categories, respectively. This 
would allow the invention to be generalized to other 
embodiments, but would not entail any revision to the 45 
solution offered. It is believed that most yield manage- 
ment systems can be described in the general terms 
given above. 

In summary, an airline seat reservation system has 
been described wherein seat reservations are controlled 50 
using, in part, a seat inventory control system. The seat 
reservation control, based on a concept termed Net- 
work-Based Expected Marginal Seat Revenue 
(EMSR), does not require the large number of variables 
required by the other network-based approaches, and it 55 
incorporates a probabilistic demand model without . 
resorting to computationally intractable integer pro- 
gramming. The computer-based seat inventory control 
system uses leg-based methods to control bookings in a 
flight network comprised of a plurality of itinerary /fare 60 
class combinations using a plurality of flight legs. When 
considering a particular flight leg, the total fare paid by 
a using the leg is discounted by taking into account the 
displacement cost of the travel on the other legs of the 
itinerary to create a virtual fare. Expected marginal seat 65 
revenues provide the displacement cost on the legs 
when computing virtual fares. Using these EMSR- 
dependent virtual fares, a leg-based optimization 



What is claimed is: 

1. An airline seat reservation system, comprising: 

(a) a programmed computer; 

(b) data storage means, connected to the programmed 
computer, for storing a database describing a flight 
network and seat reservation requests, the flight 
network comprising a plurality of flight legs a, and 
itinerary p and fare class i combinations, each flight 
leg a having a residual seating capacity Q, and 
each itinerary p and fare class i combination having 
a revenue yield P p for a seat reserved therein; 

(c) the programmed computer comprising seat assign- 
ment means for processing the database describing 
the flight network to assign seats in a flight leg a to 
one or more itinerary p and fare class i combina- 
tions, the seat assignment means comprising: 

(1) means for calculating an initial expected mar- 
ginal seat revenue (EMSR) Ac for all flight legs a; 

(2) means for computing an unnested EMSR- 
prorated virtual fare vfa for every itinerary p 
and fare class i combination that contains a par- 
ticular flight leg a having a nonzero residual 
seating capacity Q, so that: 



(3) means for calculating a new EMSR A<, for the 
particular flight leg a based on the virtual fares 
v*pja by applying Newton's method to a seating 
capacity constraint for the particular flight leg a: 



x 2 ^(Xo/0=Ca 

p i 

wherein Q 1 p is an inverse of a cumulative probabil- 
ity density function of demand for fare class i travel 
on itinerary p, thereby ensuring that a total number 
of seats assigned to the itinerary p and fare class i 
combinations are equal to the residual seating ca- 
pacity of the particular flight leg a, wherein the 
virtual fares v'^ are updated at each step of the 
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Newton's method since each step changes the 
EMSR Xq for the particular flight leg a; 

(4) means for converging the EMSR Xa for the 
particular flight leg a; 

(5) means for terminating the seat assignment 
means when the changes in the £MSR*s for 
all flight legs a are insignificant; 

(d) reservation terminal means, operatively con- 
nected to the programmed computer, for entering a 
seat reservation request for a particular itinerary p 
and fare class i combination; and 

(e) the programmed computer comprising reserva- 
tion means for receiving the seat reservation re- 
quest for the particular itinerary p and fare class i 
combination from the reservation terminal means, 
for accepting the seat reservation request in accor- 
dance with a value selected from a group compris- 
ing at least one of the following: a globally optimal 
set of EMSR's Aa s and the total, number of seats 
assigned to the itinerary pa nd fare class i combina- 
tions for recording the seat reservation request in 
the database, and for transmitting an electronic 
status indication of the seat reservation request 
from the computer to the reservation terminal 25 
means. 

2. The apparatus of claim 1, wherein the means for 
calculating further comprises means for performing a 
binary search when the EMSR \a fails to converge with 
Newton's method. 30 

3. The apparatus of claim 1, wherein the means for 
terminating further comprises means for terminating the 
seat assignment means when the changes in EMSR's 
Xo's for all flight legs a are less than a tolerance value. 

4. The apparatus of claim 1, wherein the reservation 35 
means further comprises means for accepting the seat 
reservation request when the total number of seats as- 
signed to the itinerary p and fare class i combinations is 
not exceeded. 

5. The apparatus of claim 1, wherein the reservation 40 
means further comprises means for accepting the seat 
reservation request when the seat reservation request 
would yield revenue greater than or equal to a sum of 
the EMSR's Xa's for all flight legs a in the itinerary p. 

6. An airline seat reservation system, comprising: 

(a) a programmed computer; 

(b) data storage means, connected to the programmed 
computer, for storing a database describing a flight 
network and seat reservation requests, the flight 
network comprising a plurality of flight legs a, and 
itinerary p and fare class i combinations, each flight 
leg a having a residual seating capacity Co, and 
each itinerary p and fare class i combination having 
a revenue yield Pp for a seat reserved therein; 

(c) the programmed computer comprising seat assign- 
ment means for processing the database describing 
the flight network to assign seats in a flight leg a to 
one or more itinerary p and fare class i combina- 
tions, the seat assignment means comprising: 
(i) means for calculating an initial expected mar- 
ginal sat revenue (EMSR) K for all the flight 
legs a; 

(2) means for computering a nested EMSR-prorated 
virtual fare v'^, for each itinerary p and fare class i 65 
combination that contains a particular flight leg a 
having a nonzero residual seating capacity C fl so 
that: 



45 



50 



55 



60 



(3) means for sorting the itinerary p and fare class 
i combinations into a list ordered by descending 
values of virtual fares v'^,; 

(4) means for processing the sorted list of virtual 
fares v^ one-by-one to Find an intersection point 
defining a new EMSR X*,for the particular flight 
leg a between functions: 



wherein x is an independent variable, $ a is a jth 
largest virtual fare on leg a, and nj is a probabil- 
ity that more than Q, passengers are willing to 
pay J a or more to travel on leg a; 

(5) means for converging the EMSR Xa for the 
particular flight leg a; 

(6) means for terminating the seat assignment 
means when the changes in the EMSR's Vs for 
all flight legs a are insignificant; 

(d) reservation terminal means, operatively con- 
nected to the programmed computer, for entering a 
seat reservation request for a particular itinerary p 
and fare class i combination; and 

(e) the programmed computer comprising reserva- 
tion means for receiving the seat reservation re- 
quest for the particular itinerary p and fare class i 
combination from the reservation terminal means, 
for accepting the seat reservation request in accor- 
dance with a globally optimal set of EMSR's Vs, 
for recording the seat reservation request in the 
database, and for transmitting an electronic status 
indication of the seat reservation request from the 
computer to the reservation terminal means. 

7. The apparatus of claim 6, wherein the means for 
terminating further comprises means for terminating the 
seat assignment means when the changes in EMSR's 
X fl *s for all flight legs a are less than a tolerance value. 

8. The apparatus of claim 6, wherein the reservation 
means further comprises means for accepting the seat 
reservation request when the seat reservation request 
would yield revenue greater than or equal to a sum of 
the EMSR's X^'s for all flight legs a in the itinerary p. 

9. An airline seat reservation system, comprising: 

(a) a programmed computer; 

(b) data storage means, connected to the programmed 
computer, for storing a database describing a flight 
network and seat reservation requests, the flight 
network comprising a plurality of flight legs a, and 
itinerary p and fare class i combinations, each flight 
leg a having a residual seating capacity Ga> and 
each itinerary p and fare class i combination having 
a revenue yield P p for a seat reserved therein; 

(c) the programmed control comprising seat assign- 
ment means for processing the database describing 
the flight network to assign seats in a flight leg a to 
one or more itinerary p and fare class i combina- 
tions, the seat assignment means comprising: 
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(1) means for calculating an initial expected mar- 
ginal seat revenue (EMSR) ^ for all the flight 
legs a; 

(2) means for computing a nested EMSR-differen- 
tial virtual fare v'^ for each itinerary p and fare 5 
class i combination that contains a particular 
flight leg a having a nonzero residual seating 
capacity C a so that: 




(3) means for sorting the itinerary p and fare class 13 
i combinations into a list ordered by descending 
virtual fares for the particular flight leg a; 

(4) means for processing the sorted list of virtual 
fares v' Aff one-by-one to Find an intersection point 
defining a new EMSR Xafor the particular flight 
leg a between functions: 

Kg — X 

25 

fjz* 

wherein x is an independent variable, fl is a jth 
largest virtual fare on leg a, and is a probabil- 30 
ity that more than C„ passengers are willing to 
pay the virtual fare tf a or more to travel on leg a; 

(5) means for terminating the seat assignment 
means when the changes in the EMSR's X^'s for 
all flight legs a are insignificant; 35 

(d) reservation terminal means, operatively con- 
nected to the programmed computer, for entering a 
seat reservation request for a particular itinerary p 
and fare class i combination; and 

(e) the programmed computer comprising reserva- 40 
tion means for receiving the seat reservation re- 
quest for the particular itinerary p and fare class i 
combination from the reservation terminal means, 
for accepting the seat reservation request in accor- 
dance with a globally optimal set of EMSR's Xo's, 
for recording the seat reservation request in the 
database, and for transmitting an electronic status 
indication of the seat reservation request to the 
reservation terminal means. ^ 

10. The apparatus of claim 9, wherein the means for 
terminating further comprises means for terminating the 
seat assignment means when the changes in EMSR's 
Xrt's for all flight legs a are less than a tolerance value. 

11. The apparatus of claim 9, wherein the reservation 55 
means further comprises means for accepting the seat 
reservation request when the seat reservation request 
would yield revenue greater than or equal to a sum of 
the EMSR's A* s for all flight legs a in the itinerary p. 

12. A system for allocating physical resources, com- gQ 
prising: 

(a) a computer; 

(b) data storage means, connected to the computer, 
for storing a database describing a known resource 
capacity for each of a plurality of resource catego- 65 
ries a, a known demand distribution for each of a 
plurality of demand categories z, a known revenue 
yield for a resource reserved within each demand 
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category z, and a booking limit for each demand 
category z; 

(c) the computer comprising resource assignment 
means for processing the database to assign re- 
sources in a resource category a to ne r more 
demand categories z, the resource assignment 
means comprising: 

(1) means for calculating an initial expected mar- 
ginal resource revenue (EMRR) K for all re- 
source categories a; 

(2) means for computing an unnested EMRR- 
prorated virtual price for every demand 
category z that contains a particular resource 
category a having a nonzero residual capacity 
C a so that: 

A fj\, 

b*2 

(3) means for calculating a new EMRR \ a for the 
particular demand category a based on the vir- 
tual prices v^ by applying Newton's method to 
a resource capacity constraint for the particular 
resource category a: 

wherein Q 2 is an inverse of a cumulative proba- 
bility density function of demand for demand 
category z, thereby ensuring that a total number 
of resources assigned to the demand category z 
are equal to the residual capacity Ca of the par- 
ticular resource category a, wherein the virtual 
prices are updated at each step of the New- 
ton's method since each step changes the EMRR 
X fl for the particular resource category a; 

(4) means for converging the EMRR Xa for the 
particular resource category a; 

(5) means for terminating the resource assignment 
means when the changes in the EMRR's V$ for 
all resource categories a are insignificant; 

(d) reservation terminal means, operatively con- 
nected to the computer, for entering a resource 
reservation request for a particular demand cate- 
gory z; and 

(e) the computer comprising reservation means, for 
receiving the resource reservation request for the 
particular demand category z from the reservation 
terminal means, for accepting the resource reserva- 
tion request in accordance with a globally optimal 
set of EMRR's Kt\ for recording the resource 
reservation request in the database, and for trans- 
mitting an electronic status indication of the re- 
source reservation request to the reservation termi- 
nal means. 

13. The apparatus of claim 12, wherein the means for 
calculating further comprises means for performing a 
binary search when the EMRR Kt fails to converge 
with Newton's method. 

14. The apparatus of claim 12, wherein the means for 
terminating further comprises means for terminating the 
resource assignment means when the changes in 
EMRR's Vs for all resource categories a are less than 
a tolerance value. 
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15. The apparatus of claim 12, wherein the reserva- 
tion means further comprises means for accepting the 
resource reservati n request when the total number of 
resources assigned to the demand categories z is not 
exceeded. 5 

16. The apparatus of claim 12, wherein the reserva- 
tion means further comprises means for accepting the 
resource reservation request when the resource reserva- 
tion request would yield revenue greater than or equal 

to a sum of the EMRR's for all resource categories 10 
a in the demand categories z. 

17. A system for allocating physical resources, com- 
prising: 

(a) a computer, 

(b) data storage means, connected to the computer, 15 
for storing a database describing a known resource 
capacity for each of a plurality of resource catego- 
ries a, a known demand distribution for each of a 
plurality of demand categories z, a known revenue 
yield for a resource reserved within each demand 20 
category z and a booking limit for each demand 
category z; 

(c) the computer comprising resource assignment 
means for processing the database to assign re- 



30 



. sources in a resource category a to one or more 



25 



demand categories z, the resource assignment 
means comprising: 

(1) means for calculating an initial expected mar- 
ginal resource revenue (EMRR) \a for all the 
resource categories a; 30 

(2) means for computering a nested EMRR- 
prorated virtual price v Aa for each demand cate- 
gory z that contains a particular resource cate- 
gory a having a nonzero residual capacity Q so 
that: 35 



bet 



40 



(5) means for sorting the demand categories z into 
a list ordered by descending values of virtual 
prices v^; 

(4) means for processing the sorted list of virtual 45 
prices v Ji0 one-by-one to find an intersection 
point defining a new EMRR \a for the particular 
resource category a between functions: 



(e) the computer comprising reservation means for 
receiving the resource reservation request for the 
particular demand category z from the reservation 
terminal means, for accepting the resource reserva- 
tion request in accordance with a globally optimal 
set of EMRR's Xa's, for recording the resource 
reservation request in the database, and for trans- 
mitting an electronic status indication f the re- 
source reservation request to the reservation termi- 
nal means. 

18. The apparatus of claim 17, wherein the means for 
terminating further comprises means for terminating the 
resource assignment means when the changes in 
EMRR's \a$ for all resource categories a are less than 
a tolerance value. 

19. The apparatus of claim 17, wherein the reserva- 
tion means further comprises means for accepting the 
resource reservation request when the resource reserva- 
tion request would yield revenue greater than or equal 
to a sum of the EMRR's X^'s for all resource categories 
a in the demand category z, 

20. A system for allocating physical resources, com- 
prising: 

(a) a computer; 

(b) data storage means, connected to the computer, 
for storing a database describing a known resource 
capacity for each of a plurality of resource catego- 
ries a, a known demand distribution for each of a 
plurality of demand categories z, a known revenue 
yield for a resource reserved within each demand 
category a, and a booking limit for each demand 
category z; 

(c) the computer comprising resource assignment 
means for processing the database to assign re- 
sources in a resource category a to one or more 
demand categories z, the resource assignment 
means comprising: 

(1) means for calculating an initial expected mar- 
ginal resource revenue (EMRR) Xf fl for all the 
resource categories a; 

(2) means for computing a nested EMRR-differen- 
tial virtual price v 2t jfor each demand category z 
that utilizes a particular resource category a 
having a nonzero residual capacity d so that: 



ko = jr 



A. 
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wherein x is an independent variable, & a is a jth 55 
largest virtual price in resource category a, and 
irj is a probability that more than Q, customers 
are willing to pay V' a or more for a reservation in 
resource category a; 

(5) means for converging the EMRR Xa for the 60 
particular resource categories a; 

(6) means for terminating the resource assignment 
means when the changes in the EMRR's \</s for 
all resource categories a are insignificant; 

(d) reservation terminal means, operatively con- 65 
nected to the computer, for entering a resource 
reservation request for a particular demand cate- 
gory z; and 



(3) means for sorting the demand categories z into 
a list ordered by descending virtual prices v^; 

(4) means for processing the sorted list of virtual 
prices \ Z jj one-by-one to find an intersection 
point defining a new EMRR Xjfor the particular 
resource category a between functions: 

Xo = jc 

^ = 2 fJivj f- «y_j) 
ft/*x 

wherein x is an independent variable, P a is a jth 
largest virtual price in resource category a, and 
is a probability that more than C a customers 
are willing to pay the virtual price P a or more for 
a for a reservation in resource category a; 
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(5) means for terminating the resource assignment 
means when the changes in the EMRR's XJs for 
all resource categories a arc insignificant; 

(d) reservation terminal means, opcratively con- 
nected to the computer, for entering a resource 
reservation request for a particular demand cate- 
gory z; and 

(e) The computer comprising reservation means for 
receiving the resource reservation request for the 
particular demand category z from the reservation 
terminal means, for accepting the resource reserva- 
tion request in accordance with a globally optimal 
set of EMRR's Vs. for recording the resource 
reservation request in the database, and for trans- 
mitting an electronic status indication of the re- 
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sources reservation request to the reservation ter- 
minal means. 

21. The apparatus of claim 20, wherein the means for 
terminating further comprises means for terminating the 
resource assignment means when the changes in 
EMRR's Vs for all resource categories a are less than 
a tolerance value. 

22. The apparatus of claim 20, wherein the reserva- 
tion means further comprises means for accepting the 
resource reservation request when the resource reserva- 
tion request would yield revenue greater than or equal 
to a sum of the EMRR*s X^'s for all resource categories 
a in the demand category z. 
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1 2 

TRAVEL PLANNING SYSTEM at least one travel destination and at least one travel origin 

determines a set of pricing solutions, said set of pricing 

BACKGROUND solutions represented by a structure that contains a plurality 

This invention relates to computerized travel planning of logically combinable entries that represent a second 

systems. 5 plurality of pricing solution entities and a client process that 

Travel planning systems are used to produce itineraries receives said pricing solution structure. The client process 

and prices by selecting suitable travel units from databases includes an enumeration process that extracts pricing solu- 

contaiaing geographic, schedu ling and pricing information. ^ ons ^ rom ^ structure. 

In t he airline industry, hindaiiiemal uavel Utllb fflcTCae According to a still further aspect of the invention, a travel 

' — "fftgrfls' (sequences of regularly scheduled takeofls and 10 planning system includes a server process that in response to 

landings assigned a common identifier) and "fares" (prices at least one travel destination and at least one travel origin 

published by airlines for travel between two points). The determines and represents a set of pricing solutions by a 

term "itinerary" is often used to refer to a sequence of flights directed acyclic graph data structure and a client process that 

on particular dates, and the termj'ftrjrinpr gnlmf/ pn" is often receives said directed acyclic graph. The client process uses 

- used to refer to a cornhinatirv i nf fgrpg flnH itinpmrifts t^t ^ me directed acyclic graph representation to enumerate in 

, satisfies a travefl reque st response to user preferences a set of pricing solutions. 

The databases usually contain schedule information pro- According to a still further aspect of the invention, an 

vided by airlines, typically in the so-called Standard Sched- airline travel planning system includes a server computer 

ules Information Manual (SSIM) format, and usually fares and a server process executed on said server computer, said 

published by airlines and resellers, typically provided 20 server process including a search process to search for set of 

through the intermediary Airline Tariff Publishing Company pricing solutions that determine possible set of pricing 

(ATPCO). The database may also contain "availability** solutions in accordance with at least one destination and at 

information that determines whether space is available on least one origin, said search process representing said set of 

flights, or this may be obtained through communication pricing solutions in the form of a directed acyclic graph and 

links to external sources such as airlines. 25 a client computer and a client computer process responsive 

Presently, so-called computer reservation system (CRSs) to the set of pricing solutions represented in the form of the 

operate to produce fare and schedule information. There are directed acyclic graph. The client process including a 

four generally known computer reservation systems that manipulation process that manipulates the set of pricing 

operate in the United States, Sabre®, Galileo®, Amadeus® solutions in the form of the directed acyclic graph repre- 

and WorldSpan®. The typical CRS contains a periodically sentation in response to user preferences. The manipulation 

updated central database that is accessed by subscribers such process includes a pruning process responsive to user pref- 

as travel agents through computer terminals. The subscribers erences that alters the directed acyclic graph representation 

use the computer reservation system to determine what ^ such a manner so as to eliminate undesirable pricing 

airline flights are operating in a given market, what fares are solutions, and an enumeration process responsive to user 

offered and whether seats are available on flights to make 35 preferences that produces a sorted subset of the pricing 

bookings and issue tickets to clients. solutions represented in the directed acyclic graph. 

The computer reservation systems typically conduct One or more advantages are provided by the some of the 

searches using the information contained in the database to aspects of the invention. The client process receives a set of 

produce itineraries that satisfy a received request. The search ^ pricing solutions provided in a compact representation. A 

results are sorted and returned to the requester's computer preferred, compact representation of the set of pricing solu- 

for display. tions is as a data structure comprising a plurality of nodes 

Typically, the number of possible itineraries and pricing mat caD te logically manipulated using value functions to 

solutions that are returned by a CRS is a small portion of the enumerate a set of pricing solutions. One preferred example 

total set that may satisfy a passengers request. 45 & a graph data structure type particularly a directed acyclic 

graph that contains nodes that can be logically manipulated 

SUMMARY OF THE INVENTION or combined to extract a plurality of pricing solutions. The 

According to one aspect of the invention, a travel plan- client, can store and/or logically manipulate the set of 

ning system includes a perver process t hat determines travel pricing solutions to extract or display a subset of the set of 

planning information in response to travel request lnhjrma^ 50 Pacing solutions without the need for additional intervention 

, tion and a client process that receives said travel planning DV tne server. 

» « , . 1 1 A in formation. Hie client process-includes a manip ulation 

/VfoVWf UlQtiTT g^^ SXIriy informarion -Tn BRIEF DESCRIPTION OF THE DRAWINGS 

one embodiment, the manipulation process can operate on ^ f oreg oing features and other aspects of the invention 

the travel p lanning information in accordance with at least 55 ^ ^ described in further detail by the accompanying 

one user preference input . drawings, in which: 

- Accormng to anotner aspect of the invention, an airline FIG. 1 is a block diagram of a client server travel planning 

travel planning system includes a scheduler that produces a system 

set of .flights in resp onse, tn a user specified q uery, a taring ^.^ _ . _ , ^ , , . u 

- J^m that provides jares for the setsof flights, jnTwmc h 6 0 ™. 2 is a flow chart showing a server prc^ss used m the 

represents the sets of flig hts and fares as a set of logically system of FIG. 1. 

_ manipulata ble nodes in a data structure. 'I tie system also FIG. 3 is a flow chart showing a client process used in the 

includes an enumer ation process that pib cesses the data system of FIG. 1. 

structure to extract flight-fare components from nodes in the FIGS. 3A-3B are diagrammatic representations of pricing 

data structure. 65 graphs. 

According to a still further aspect of the invention, a travel FIGS. 4A-4B are flow charts showing a faring process 

planning system includes a server process that in response to used in the server process of FIG. 2. 
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FIG. 5 is a flow chart showing a process to decompose an information as a result of a user query. For example, the 

itinerary into faring atoms used in the process of FIG. 4A- server process 12 can produce routes or airline suggestions, 

FIG. 6 is a flow chart showing a process for partitioning °P timal lravel iimcs and suggestions for alternative requests, 

itineraries used in the process of FIG. 5. j The travel planning system 10 also includes a plurality of 
... c 1- i5 databases 20a, 20b which store industry-standard lnforma- 

FIG. 7 is a flow chart showing a process for p applying rules tion ^ to travel ( airlinej buSj railroad? etc ). For 

to faring atoms used in the faring process of FIG. 4A. example, database 20a can store the Airline Tariff Publishing 

FIGS. 8A-8C are flow charts showing a process for Company database of published airline fares and their 

retrieving fare rules. associated rules, routings and other provisions, the so-called 

FIG. 9 is a flow chart showing a process for applying fare 10 ATPCO database. Database 204? can be an inventory of 

rules, current availability of airline information for a particular 

'~ . n . n , _ , c j . • • carrier and so forth. The databases 20a-20i> are typically 

FIG 10 is a flow chart showmg a process ^ determining ^ ^ d riodicall b awe Wremote 

pnceable units used in the faring process of FIGS. 4A-4B. resources 21fl> 2 lb that maintain the respective databases. 

FIG. 10A is a flow chart showing a process for enumer- -j^ sys tem 10 also includes a plurality of clients 30a-30c 
ating collections of sets of faring components used in the 15 (g eDera lly 30) implemented by terminals or preferably per- 
process of FIG. 10. sonal computers. The clients 30a-30c are coupled to the 

FIG. U is a flow chart showing a process for enumerating server 12 via a network 22 which is also used to couple the 

collections of faring components used in the process of FIG. remote resources (21a-21c) that supply the databases 

10 20o-20£> to the server 12. The network 22 can be any local 

Titr- 1-1 • „ a_ . „^ • r , M „™ t - 20 or wide area network or an arrangement such as the Internet. 

FIG. 12 is a flow chart showing a process for representing m ^ n „ 0 «. , , ^ . . 

• . i„ , • n r nnt „ ° „ t :„ n The chents 30a-30c are preferably smart clients. That is, 

pnceable units in a compact representation. *: . J _ ' 

r using client 30c as an illustrative example, client 30c 

FIGS. 13-15 are flow charts showmg processes for deter- includes a client computer system 32 including a computer 

mining pnceable units. memory or storage media 34 that stores a client process 36 

FIG. 16 is a flow chart showing a process for producing 25 and a set of pricing solutions 38. The set of pricing solutions 

slice label sets. 38 in one embodiment is provided from the server process 

FIG. 17 is a flow chart showing the process for construct- ™ *nd comprises a set of fares that are valid for a journey, 

ing a pricing graph. and associated information linking the fares to the flight 

FIG. 18 is a block diagram showing the relationship segments of the journey, 

between the pricing graph £d a graphical user interface for 30 ™ e set of P™"* solutl0ns 3 f 15 < *? me " 01 ?. th f 

the travel planning system of FIG. 1. \ 2 m ^"f '° 4 Mer T "f 1 * 0m the clleat i0c * 

/ . * , . the server 12. The server 12 executes the server process 15 

FIG. 19 is a flow chart showing various enumeration using the scheduling process 16 and the faring process 18 to 

functions. produce a set of pricing solutions for a particular journey. If 

FIG. 20 is a diagram of a window depicting a user 35 requested by the client, for example client 30c, the server 12 

interface. will deliver the set of pricing solutions 38 to the requesting 

FIG. 21 is a diagram of a window used in an initial query; client 30c. Under control of the client process 36, the 

FIG. 22 is a diagram of a window depicting an exemplary requesting client 30c can store and/or logically manipulate 

solution of a one-way travel request. the set of pricing solutions 38 to extract or display a subset 

FIG. 23 is a diagram of a window depicting an itinerary 40 of te ** of pricing solutions as a display representation 41 

and associated fares corresponding to one of the solutions °° tli e monitor 40 

depicted in FIG. 21. SERVER PROCESS 

' nijr ,_.. c - j j • t Referring now to FIG. 2, the server process 18 is prefer- 

F1G. 24 is a diagram of a window depicting an exemplary U1 * tU • 11 u ♦ ij u 

1A . - j * . * i . ably executed on the server computer 12 but could be 

solution of round trip travel request. * j a. v * t L i0 • 

r . . . 45 executed on the client computer 32. The server process 18 is 

FIG. 25 is a diagram of a window depicting an outbound responsive to a user mput qucry & The user input query 48 

itinerary and a possible return itinerary and associated fares WQuld mcludc minimal information needed to 

corresponding to one of the solutions depicted in FIG. 24. detcrmine a ^ of pricin g solutions. This information typi- 

FIG. 26 shows the window generally depicted in conjunc- ca Uy requires at a minimum, an origin and a destination for 

tion with FIG. 24 modified based upon a user selected 50 travel. In addition, the information could also include times, 

criteria. dates and so forth. 

FIG. 27 shows a window depicting a histogram. This query 48 is fed to the scheduler process 16 that 

lynnM produces a large number of itineraries, that is, sequences of 
DETAILED DESCRIPTION flight ^gm^ between the origin and destination for each 
Referring now to FIG. 1, a travel planning system 10 is 55 slice of a journey. Examples of scheduler systems that may 
shown. The travel planning system can be used with various be used include the OAG Flight Desk (Official Airlines 
forms of travel such as airline, bus and railroad and is Guide, a division of Reed Travel Group) or schedule corn- 
particularly adapted for air travel. It includes a server ponents of computer reservation systems (CRS's) such as 
computer 12 having a computer memory or storage media Sabre®, Apollo®, Amadeus® and WorldSpan®. It is pref- 
14 storing a server process 15. The server process includes 60 erable in order to obtain the largest number of possible 
a scheduler process 16 and a faring process 18. The sched- itineraries to use a scheduler with dynamic connection 
uler process 16 is any suitable scheduler process that will generation. Such a scheduler is described in co-pending 
produce from a travel request sets of flights that can satisfy patent application entitled SCHEDULER SYSTEM FOR 
the request. The faring process 18 is a process that deter- TRAVEL PLANNING SYSTEM, Ser. No. 09/109,622, filed 
mines a set of valid fares and links the set of valid fares to 65 on Jul. 2, 1998 by Carl G. deMarcken et al. pending and 
the sets of flights to form a pricing solution. The server assigned to the assignee of the invention and incorporated 
process 15 can be configured to produce other travel-related herein by reference. 
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The scheduler process 16 provides the itineraries to a 
faring process 18. The faring process 18 provides a set of 
pricing solutions 38 by finding valid fares corresponding to 
the itineraries produced by the scheduler process 16. The 
faring process 18 validates the fares for inclusion in the set 5 
of pricing solutions 38. 

The set of pricing solutions 38 is used by an availability 
system 58 that interrogates an airline inventory database 20b 
to determine whether there are seats available on particular 
flights for particular pricing solutions. The availability sys- 1Q 
tern 58 uses the airline inventory database 2Qb as a filter to 
remove from the set of pricing solutions 38 those pricing 
solutions for which there are not available seats. The avail- 
ability system 58 is shown after the faring process 18. 
However, it could be included at nearly any point in the 
server process 18. In addition, it is shown being fed by the 15 
pricing solution whea it may only receive flight information 
from the scheduler process 16 depending on the airline. 

The client system 30c receives the results from the server 
process 18. These results are the set of pricing solutions 38 
and/or pricing solutions based upon availability. The client 20 
process 36 executed in the client 30c uses this information 
or a subset of it to access a booking system 62 to provide a 
booking and reservation for a user selected, enumerated 
pricing solution, as will be described below. 
CLIENT PROCESS 25 

Referring now to FIG. 3, the client process 36 receives a 
listing of possible itineraries from the scheduler process 16 
as well as the set of fares from the faring process 18 or the 
availability system 58. The set of pricing solutions 38, if 
obtained from the faring process 18, will include a large ^ 
number of pricing solutions for which there is not any 
available inventory. Therefore, the components would need 
to be first checked out with an airline prior to booking. The 
set of pricing solutions 38 if obtained after the availability 
system 58 should contain pricing solutions which have a 
high degree of availability for booking on an airline. 

In one embodiment, the set of pricing solutions 38 is 
provided in a compact representation 38 1 . A preferred, com- 
pact representation 38' of the set of pricing solutions 38 is as 
a data structure comprising a plurality of nodes including 
itineraries and fares and that can be Logically manipulated 
using value functions to enumerate a set of pricing solutions. 
One preferred example is a graph data structure type par- 
ticularly a directed acyclic graph (DAG) that contains nodes 
that can be logically manipulated or combined 74 to extract 
75 a plurality of pricing solutions for display 72. 

The client process 36 receives the flight information from 
scheduler process 16 and the pricing solution from the faring 
process 18 or the availability system 56 and enumerates 
pricing solutions from the directed acyclic graph (DAG) ^ 
representation. The enumerated set 70 of pricing solutions is 
rendered or displayed 72 in a graphical user interface 41 on 
the client monitor 40 (FIG, 1) in a manner as will be 
described below. 
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In response to user input 76, the client 40 can manipulate 
74 travel options and can query the local copy of the DAG 
to produce and display a subset of pricing solutions enu- 
merated from the DAG that satisfy the query 76. The 
manipulation process used to control the display and change 
the travel options will be described below. 

A directed acyclic graph (DAG) is used to represent the 
compact set of pricing solutions 38* since, in general, the 
number of nodes needed to represent a typical pricing 
solution will be substantially less than the actual number of 
pricing solutions represented by the DAG. This significandy 
increases the efficiency of transfer of a set of pricing 
solutions 38 from the server process 18 to the client process 
36. The DAG representation also minimizes the storage 
requirements for the set of pricing solutions 38. The DAG 
representation permits the use of powerful search, sorting 
and manipulation processes to produce various subsets of set 
of pricing solutions in an efficient manner. As used herein, 
a directed acyclic graph (DAG) is a set of nodes connected 
by directed arcs, that have no loops of arcs in the same 
direction. If a node A is connected to a node B via an arc 
A-B, then A is called a parent of B, and B is called a child 
of A. Each node may have zero, one or many parents and 
zero, one or many children. As used herein, a pricing 
solution that is represented by a graph will be referred to as 
a pricing graph. 
PRICING-GRAPH 

A pricing graph that is produced by the faring process 18 
and that represents a pricing solution includes three types of 
nodes. The first type of node is an exclusive node, i.e., "OR" 
node. An OR node N with children A, B and C represents an 
exclusive choice between A, B and C. In other words, a 
pricing-solution involving node N contains either the fares 
and itineraries represented by A, or by B, or by C. 

The second type of node is a collection node, i.e., an 
"AND" node. An AND node N with children A, B and C 
represents the sum of A, B and C. In other words, a pricing 
solution involving N contains all the fares and itineraries 
found within A, B and C. 

The third type of node is a terminal node. Terminal nodes 
are used to hold pricing objects. Pricing objects include 
fares, itineraries, surcharges, routes, prices, booking codes, 
taxes, rules/restrictions and other information of the user or 
information that might be part of a travel option. 
Collectively, "AND" and "OR" nodes are non-terminal 
nodes. 

An example of the pricing-graph for a hypothetical round- 
trip journey is presented below in TABLE 1. For each node, 
its type and children are listed. If a node is a terminal, the 
fare or itinerary is provided. Many nodes in the pricing 
graph have more than one parent. 



TABLE 1 



Node Type ChildicD Object 



0 OR Nodes 1, 2, 3 

1 AND Nodes 10, 14, 17, 17 

2 AND Nodes 4, 5 

3 AND Nodes 13, 15, 19, 19 

4 OR Nodes 8, 9 

5 OR Nodes 6, 7 

6 AND Nodes 14, 16 

7 AND Nodes 15, 18 

8 AND Nodes 13, 16 
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TABLE 1 -continued 



Node Type Children Object 



9 AND Nodes 13, 18 

10 OR Nodes 11, 12 

11 I tin. Slice 1: BOS— LAX UA023 

12 Itin. Slice 1: BOS-DFW UA100, DFW-LAX UA103 

13 Itin. Siicc 1: BOS— SAN NW222 

14 Itin. Slice 2: LAX— BOS UA515 

15 Itin. Slice 2: SAN—BOS NW223 

16 Fare UA BOS-LAX One-way «Y' 

17 Fare UA BOS-LAX Round-trip "QE7NR" 

18 Fare NW BOS-SAN One-way "F" 

19 Fare NW BOS-SAN Round-trip "H7NR" 



This pricing-graph represents a total of nine pricing 
solutions. These solutions can be extracted from the pricing- 
graph by descending from the root node, node 0. At every 
OR node a choice between children is made, and the choice 
determines the pricing-sohition that results. At every AND 
node each child branch is descended, and the results are 
combined. 

The term BOS-»LAX UA023 is an itinerary which uses 
standard nomenclature to represent airports BOS and LAX, 
airline UA, and flight number 023. In general, conventional 
nomenclature used in the airline industry will be used herein. 

The set of pricing-solutions that represented in the 
pricing-graph is presented in TABLE 2 below. 



0 allows for a choice between nodes 1, 2, and 3. For pricing 
solution No. 1, Node 1 is chosen. Node 1 is the AND node 
that points to nodes 10 and 14, and has two pointers to node 
17. Node 10 is an OR node which provides a choice of either 
nodes 11 or nodes 12. Node 11 as shown in FIG. 3A 
corresponds to a terminal node, the itinerary (BOS-LAX UA 
023). Node 12 corresponds to a terminal node, the itinerary 
BOS-DFN UA 100, DFN-LAX UA 103. This second choice 
in node 10 will provide pricing solutions corresponding to 
numbers 4-6, respectively. Therefore, selecting node 11 
provides the itinerary for the first slice of solution 1. The fare 
for pricing solution 1 is provided by node 17 which has two 
pointers, one for each slice, to the fare "US BOS-LAX RT 



20 



TABLE 2 



Solution Number Itineraries 


Fares 


1 


Slice 1: BOS-LAX UA023 


UA BOS-LAX RT "QE7NR" 




Slice 2: LAX-BOS UA515 


UA BOS-LAX RT "QE7NR" 


2 


Slice 1: BOS-LAX UA023 


UA BOS-LAX OW "Y" 




Slice 2: LAX-BOS UA515 


UA BOS-LAX OW "V 


3 


Slice 1: BOS-LAX UA023 


UA BOS-LAX OW "T* 




Slice 2: SAN-BOS NW223 


NW BOS-SAN OW "F* 


4 


Slice 1: BOS-DFW TJA100, DFW_LAX UA103 


UA BOS-LAX RT "QE7NR" 




Slice 2: LAX-BOS UA515 


UA BOS-LAX RT "QE7NR" 


5 


Slice 1: BOS-DFW UA100, CFW_LAX TJA103 


UA BOS- LAX OW "Y" 




Slice 2: LAX-BOS UA515 


UA BOS-LAX OW T' 


6 


Slice 1: BOS-DFW UA100, DFW_LAX UA103 


UA BOS-LAX OW "Y" 




Slice 2: SAN— BOS NW223 


NW BOS-SAN OW **F* 


7 


Slice 1: BOS-SAN NW222 


NW BOS-SAN OW "F" 




Slice 2: LAX-BOS UA515 


UA BOS-LAX OW "Y" 


8 


Slice 1: BOS— SAN NW222 


NW BOS-SAN RT "H7NR" 




Slice 2: SAN-BOS NW223 


NW BOS-SAN RT "H7NR" 


9 


Slice 1: BOS-SAN NW222 


NW BOS-SAN OW tt F' 




Slice 2: SAN— BOS NW223 


NW BOS-SAN OW "F" 



The pricing-graph encodes the requirement that two itin- 
eraries are combined, one from slice 1 and one from slice 2, 
to form a pricing solution. Further, each itinerary is spanned 
by fares. In this case each pricing solution involves two 
fares, and round-trip fares are combined with like round-trip 55 
fares. In most circumstances, the number of nodes in the 
pricing-graph is small compared to the number of pricing- 
solutions those nodes represent. In many cases, a graph of 
10,000 or so nodes can represent more than 1,000,000,000 
pricing-solutions. 60 

Referring now to FIG. 3A, the nodes of the pricing graph 
corresponding to Table 1 are shown, as an example. This 
figure illustrates the manner in which nodes in the pricing 
graph data structure as represented in Table 1 are combined 
to provide the pricing solutions shown in Table 2. Using 65 
pricing solution No. 1 (from TABLE 2) as an example, it can 
be shown that starting at the top of the graph at node 0, node 



QE7NR" corresponding to the fare shown for pricing solu- 
tion no. 1 in Table 2 for the first slice. The second itinerary 
for pricing solution no. 1 is provided by node 14 which is 
referenced in AND node 1 that points to the itinerary 
LAX-BOS UA 515. The corresponding fare is also from 
terminal node 17 since it is a round trip fare UA BOS-LAX 
RT QE7NR. 

A second one of the pricing solutions, for example, the 
pricing solution 4 incorporating the terminal node 12 is 
provided by starting at node 0, and using node 1. Node 1 is 
an AND node requiring that nodes 17 (twice), node 10, and 
node 14 be included. Node 10 is an OR node as mentioned 
above and is used to select node 12 which is the itinerary 
including segments "BOS-^DFW UA 100" and 
"DFW-LAX UA 103". From node 1, node 14 the return 
itinerary LAX-BOS UA 515 also is reached. Node 17 also 
is chosen which contain the round trip fares. Similarly, the 
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remaining ones of the pricing solutions can be extracted 
from the pricing graph in the same manner as the two 
examples given above. 

As mentioned above, a graph will typically have many 
more pricing solutions than nodes in the graph. The example 
just illustrated in conjunction with FIG. 3A has 9 pricing 
solutions and 19 nodes which is an exception to that general 



10 



nodes. The pricing graph has a combined total of 43 nodes 
to represent 876 pricing solutions. 

FIG. 3B shows examples of a pricing graph for a round 
trip LAX-BOS journey. This example shown in FIG. 3B is 
generally more representative of an outcome of a faring 
search. That is, generally the pricing graph represents more 
pricing solutions than nodes contained in the graph. 



TABLE 3 



Node Type 


Children 


Object 


0 


AND 


Nodes 1, 6, 11 




1 


OR 


Nodes 2, 3, 4 




2 


AND 


Nodes 5, 40 




3 


AND 


Nodes 41, 41 




4 


AND 


Nodes 42, 42 




5 


OR 


Nodes 39, 40 




6 


OR 


Nodes 7, 8, 9 




7 


AND 


Nodes 20, 10 




8 


AND 


Nodes 21, 10 




9 


AND 


Nodes 22, 10 




10 


OR 


Nodes 23, 24, 25, 26 




11 


OR 


Nodes 12, 13, 14, 
16, 17, 18 




12 


AND 


Nodes 27, 15 




13 


AND 


Nodes 28, 15 




14 


AND 


Nodes 29, 15 




15 


AND 


Nodes 30, 31, 32 




16 


AND 


Nodes 33, 19 




17 


AND 


Nodes 34, 19 




18 


AND 


Nodes 35, 19 




19 


OR 


Nodes 36, 37, 38 




20 


[tin. 




Slice 1: LAX-*DFW NW100, DFW-»BQS AA223 


21 


[tin. 




Slice 1: LAX^-DFW NW137, DFW-BOS AA223 


22 


[tin. 




Slice 1: LAX— DFW NW137, DFW-BOS AA41 4 


23 


Fare 




DFW, LAX NW "Y" OW 


24 


Fare 




DFW, LAX NW "F* OW 


25 


Fare 




DFW, LAX NW "C" OW 


26 


Fare 




DFW, LAX NW "QA7" OW 


27 


[tin. 




Slice 2: BOS— DFW AA67, DFW— LAX C0716 


28 


[tin. 




Slice 2: BOS— DFW AA67, DFW— LAX C0717 


29 


[tin. 




Slice 2: BOS— DFW AA67, DFW— LAX C0719 


30 


Fare 




DFW, LAX CO M F' OW 


31 


Fare 




DFW, LAX CO "C" OW 


32 


Fare 




DFW, LAX CO "TT OW 


33 


[tin. 




Slice 2: BOS— DFW AA852, DFW— LAX DL186 


34 


[tin. 




Slice 2: BOS— DFW AA852, DFW— LAX DL180 


35 


[tin. 




Slice 2: BOS— DFW AA852, DFW— LAX DL343 


36 


Fare 




DFW, LAX DL "F* OW 


37 


Fare 




DFW, LAX DL "C" OW 


38 


Fare 




DFW, LAX DL "Y" OW 


39 


Fare 




DFW, BOS AA "QE7NR" KT 


40 


Fare 




DFW, BOS AA "QE7IP" KT 


41 


Fare 




DFW, BOS AA "QE14NR" RT 


42 


Fare 




DFW, BOS AA "QE21NR" RT 



rule. Another example of a pricing graph which does satisfy 50 
that general observation is shown in conjunction with FIG. 
3B. 

Referring now to FIG. 3B, a pricing graph is shown 
having 43 nodes N0-N42 that when combined represent 856 55 
pricing solutions. Each node in the pricing graph has a 
number associated with it corresponding to the number of 
pricing solutions that is represents. In order to make this 
illustration of manageable size, identifiers (representing the 
nodes of the terminals) are substituted in the pricing graph 60 
for the actual terminal objects of the graph. Thus, as shown 
in FIG. 3B, outbound and return itineraries, and fare nodes 
are represented by the Nodes N2Q-N42. 

This pricing graph (TABLE 3) has 9 itineraries which can 65 
be combined with 14 fares represented by 13 AND nodes 
and 7 OR nodes. The pricing objects are represented by 23 



THE FARING SYSTEM 

Referring now to FIGS. 4Aand 4B, the faring process 18 
includes a process 80 to retrieve itinerary sets for all slices 
in an itinerary. The itinerary sets are provided from the 
scheduler process 16 for each slice of a journey where a slice 
corresponds to a direction of travel. Thus, for example, for 
a round trip journey there would be two slices, one for the 
outbound part of the journey and one for the return part of 
the journey. The faring process 18 decomposes 82 the 
itinerary into faring atoms. As used herein, faring atoms 
refer to a sequence of flight segments or equivalently legs 
that are spanned by a single fare. For example, the itinerary 

UA005 from DFW to BOS at 12:30 on 12NOV 
UA010 from BOS to YYZ at 18:00 on 12NOV 
AC121 from YYZ to YVR at 01:00 on 13NOV 
permits the following faring-atoms as shown in TABLE 4. 



55 
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TABLE 4 


Faring-Atom Number 


Legs and Departure Tunes 


a 


DFW-BOS UA005 12NOV 12:30 


2 


BOS^YYZ UA010 12NOV 18:00 


3 


DFW-BOS UA005 12NOV 12:30 




BOS^YYZ UA011 12NOV 18:00 


4 


YYZ^YVR AC121 13NOV 01:00 



A faring atom is represented by a data structure that 
preferably includes the following fields as shown in TABLE 

5: 

TABLE 5 

Faring-Atom fields Use 
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lcgs-and-departure- 
times 

faring-market 
cached- results 



priceable-u nit-labels 



A list of legs and their departure times and dates. 

The faring-market that this faring-atom is in. 
A storage space used to eliminate redundant 
computation in the rule-checking process. As rule 
record- 2s are applied to faring-atoms, the results 
are stored in this field. It the same record-2 is 
applied again, the answer is retrieved rather than 
recomputed. 

A list of the priceable-unit-labels that the 
faring-atom enters into. 



After the faring process 18 decomposes the itineraries into 
faring atoms, the faring process 18 retrieves fares 84 and 
rules 86 for each faring atom by accessing the fares/rules 
database 20a mentioned above. At this point a fare's routing 
is retrieved from a routing database and applied to a faring 
atom. If the routing test fails, the fare cannot be applied to 
the faring atom and a fare component is not built. 

The faring process 18 applies the rules 88 to the faring 
atoms to produce fare components. Fare-components are 
combinations of faring-atoms and fares. Fare-components 
(TABLE 6) are produced if a fare's rules pass a preliminary 
check on a faring-atom. They are used to store deferred rules 
(e.g., deferred record-2s and combinability record-2s) that 
are applied at a later stage of processing SSa. Fare compo- 
nents also store extra information produced during the 
rule-checking process, such as information about surcharges 
and penalties and discounts that are applied to the base fare 
price. 

TABLE 6 

Fare-Component fields Use 



fare 

faring-atom 
deferred- record-2s 

combinab ility-reco rd-2 



surcharges 



The fare-component's fare. 

The fare-component's faring-atom. 

A list of non-category- 10 record-2s that have 

not been fully evaluated. 

If the fare's rules include a category- 10 

("Fare Combinability'' record-2, it is stored 

here. 

A list of surcharges, penalties, discounts and 
other pieces of information produced during 
the rule-checking process. 



40 
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From the fare components the faring process 18 con- 
structs 90 priceable units. For certain types of rules such as 
those which require access to fares and/or flights from 
outside of the fare component, those rules are stored in the 
fare component for later or deferred evaluation. The price- 
able unit process 90, takes valid fare components and 
constructs priceable units from the fare components. This 
process 90 involves grouping fare components from differ- 
ent slices and checking fare component combination restric- 
tions. At this stage of processing, the rules deferred in step 
88 are reapplied. 
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Priceable units are represented by price able-unit -cores 
and priceable-unit-labels. Priceable-unit-cores are collec- 
tions of fares and other information associated with fares 
within a priceable-unit, such as discounts and penalties and 
surcharges. Priceable-unit-cores (TABLE 7) are referenced 
by priceable-unit-labels. 



TABLE 7 


Priceablc-Unit-Core 




fields 


Use 


fares 


A list of fares. 


slice- numbers 


A list of the slices the tares originate from. 


surcharges 


A list of surcharges, penalties, discounts and 




other pieces of information produced during the 




rule-checking process. 



20 



Priceable-unit-labels group a set of priceable-unit-cores with 
sets of faring-atoms. Together, they are used to represent sets 
of priceable-units (TABLE 8). 



TABLE 8 



Proceab le-Unit- Label 




fields 


Use 


priceable-unit-cores 


A set of priceable-unit cores. 


slice- numbers 


A list of the slices the fares and faring-atoms 




originate from. 


faring-atom-scts 


A list of sets of faring-atoms, one per slice. 



30 When all the fare components within a priceable unit are 
known, rules that were deferred from the processing 88 are 
applied 92 to the priceable unit sets of faring atoms. 

After evaluation of the deferred record-2s at the priceable 
unit stage, the itineraries and priceable units are grouped 
35 together into complete set of pricing solutions. This occurs 
by a link process 94 that links itineraries to corresponding 
pricing units from different slices to provide 96 the pricing 
solution. At this juncture, any remaining cross priceable unit 
fare combinability checks are performed to eliminate invalid 
combinations. 

The linking process involves two additional data struc- 
tures slice-label-sets and open-label-sets. Slice-label-sets 
group itinerary divisions by the multi-slice priceable-unit- 
labels they can enter into. In each slice of a journey, a unique 
slice-label-set is constructed for every set of multi-slice 
priceable-unit-labels. Each slice-label-set stores both the set 
of multi-slice priceable-unit-labels and a set of itinerary- 
label-holders, which contain single-slice priceable-unit- 
labels on a per-itinerary basis. Each slice-label-set is a pair 
of an itinerary and a set of divisioo-label-holders. Each of 
these division-label-holders is a pair of a division and a set 
of sets of single-slice priceable-unit-labels (TABLE 9). 



TABLE 9 



Slice-Label-Set fields 


Use 


multi-sl ice- PU-labels 


A set of multi-sl ice PU-labels. 


itinerary-label- holders 


A set of itinerary- label- holders. 


Itinerary-Label- Holder fields 


Use 


itinerary 


An itinerary. 


di vis ion-label-holders 


A set of division-label-holders. 


Division-Label- Holder fields 


Use 


division 


An itinerary division. 


singie-sl ice-PU- label-sets 


A set of sets of single-slice PU- labels. 
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Open-label-sets (TABLE 10) are used to summarize the state 
of the linking process 94. Each is a set of "open" multi-slice 
priceable-unit-labels and a set of backward-links. Each of 
these backward-links is a pair of a slice-label-set and an 
open-label-set. 



TABLE 10 



Open- Label-Set fields 


Use 


open-PU-labels 


A set of open multi-slice PU- labels. 


backward-links 


A set of backward-links. 


Backward- Link fields 


Use 


slice-label -set 


A slice-label-seL 


open-label-set 


An open- label-set 



The pricing solution resulting from the linking process 94 
is used to construct a pricing graph from the various data 
structures built during the preceding processes. This pricing 
graph is transmitted to the cheat process or can be stored fbr 
later use or transmission. A pseudocode representation of the 
high level processing logic involved in the above search 
procedure is set out below in TABLE 11. 
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Referring now to FIG. 6, itineraries are partitioned into 
divisions of faring atoms by examining HO for each itiner- 
ary whether or not the itinerary includes more than one leg 
112 on the same airline 114. For each sequence on the same 

5 airline, a faring-atom is produced. If the sequence has more 
than one leg, the sequence is also split into multiple faring- 
atoms (at 116), resulting in more than one division of the 
itinerary into a set of faring-atoms. The process checks 118 

!0 whether fares exist for the airline in the markets spanned by 
each faring atom. Otherwise, the process will branch from 
the examination process 112 and the airline check process 
114 to a fare check process 118 to check in the fare database 
20a that a fare exists for the airline in the market spanned by 

15 the faring atom. If all of the faring atoms within a division 
have at least one fare in the market, a division for the market 
is produced at 120. Another possible implementation creates 
divisions by producing all possible partitions of legs into 

20 faring-atoms. 

A high-level pseudocode representation for the algorithm 
that generates faring atoms, faring markets and faring divi- 
sions for each itinerary within a slice is set forth below in 
TABLE 12. 



TABLE 11 



price-itinerary-6ets(itinerary-sets, fare-database, rule-database, routing-database, environmental-Information) 

// 

// itinerary-sets is a set of sets of itineraries, one per slice. 

// environmental- information contains information about the passenger, the current date, the location 

// where tickets will be purchased, and other non-itinerary-based information that is necessary for applying 

// fare rules. 

// 

Let faring- market-sets = {} 

// Construct itinerary-divisions, faring- markets and faring-atoms. 
Let slice-number - 1 
For itinerary-set in itinerary-sets 
// 

// create-divisions constructs the itinerary-divisions, faring- markets and faring-atoms for 

// all the itineraries within a slice. It returns a set of faring-markets. 

Caring-market-sets += create-divisionsfitineraries, slice-number, fare-database) 

slice-number += 1 
// Apply fare rules, constructing fare-components in each faring-markeL 
For fa ring- market-set in faring- market-sets 

// 

// apply- fare-rules constructs fare-components for each faring- market within a slice. 

// This process contains pseudo-code for apply-fa re-rules. 

apply- fare- rules(faring-market-set, fare-database, rule-database, 
routing-database, environmental-information) 
// Create priceable-uoits. 
// for create-priceable -units 
create -priceable-units(faring-market-sets) 

// Link itineraries between slices. This procedure returns either nil, if there are no pricing-solutions, or 
// a "root" open-Iabel-seL This process is described in link-itineraries 
Let root-object - link- itineraries(itinerary- sets) 
If (root-object = nil) 
return (nil) 

// Create the pricing-graph from the data-structures that have been built in the preceding steps. 
// This process includes psedo-codc for create- pricing- graph. 
Let root-node = create-pricing-graph(root-object) 
// Return the pricing graph, 
return (root- node) 



Referring now to FIG. 5, the process 82 to decompose an 
itinerary into faring atoms includes a retrieval process 100 
that retrieves all itineraries for all slices in a journey. For 
each itinerary in each slice, the process 82 groups faring 65 
atoms by faring markets at 104 and partitions itineraries into 
the divisions of faring atoms at 106. 
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create -divisions(itineraries, slice-number, Care-database) 
Let flaring-atoms = {} 
Let faring- markets - {} 

Subroutine get-&ring-market(origin-airport, destination-airport, airline) 
Let origin-city « city(origin- airport) 
Let destination-city - dty(destination-aiiport) 

Let prcvicus-faring-maiket « nnd(<origin-city, destination-city, air lino, faring-markets) 
If (previous-faring-market) 

re turn (previous-faring- market) 

Else 

If (fares-exis^origin-city, destination-city, airline)) 
Let faring- market - new-faring- market( ) 
fa rin g- ma rke Lsl ice-number = slice-number 
faring- markeLorigiin-city = origin-city 
faring- markeLdestination-city - destination-city 
faring-market airline = airline 
faring- rnarkeLfaring-atoms = {} 
faring-markets +- faring-market 
return(faring-market) 

Else 

return(nil) 

Subroutine ge*-fermg-atom(legs-and-departure- times, origin-airport, destination-airport, airline) 
Lei previous- faring-atom - fmd(legs-and-der^rtwe-times, faring-atoms) 
If (previous-faring-atom) 

rcturn(previous-faring-atom) 

Else 

Let faring-market » get-faring-niarket(origin-airport, destination-airport, airline) 
If (faring-market <> nil) 

Let faring-atom - new-faring-atom( ) 

faring-atom. faring- market = faring-market 

faring-atoni.legs-and-departure-times - legs-and-departure- times 

faring-atom.priceabIe-unit- labels - {} 

faring-atom. cached-results = {} 

faring-rnarketfaring-atorns +- new-faring-atom 

faring-atoms += faring-atom 

return(faring-atom) 

Else 

return(nil) 

Subroutine get-orUine-divisionsQegs-and-departure-times, origin^airport, destination-airport, airline) 
Let online-divisions - {} 

Let aumbcr-of-legs = length(legs-and-oxparturc-times) 

Let single- faring-atom = get-faring-atomQegs-and-departure- times, origin-airport, destination-airport, airline) 
If (single-faring-atom <> nil) 

online-divisions += list^single-faring-atom) 
For i from 1 to number-of-legs - 3 

Let legs-and-departure-timesl - legs-and-departure-times[l . . . i] 

Let legs-and-departure-times2 = legs-and-departure- times[i+l . . . number-of-tegs] 

Let destination-airportl = destwation-airoort(farmg-atam-legsl) 

Let origin-airport2 - origin-airport(faring-atom-legs2) 

If (is-not-same-mght-scgnient(tegs-and-departure-timesl, lcgs-and-dcparturc-times2)) 
Let faring-atom 1 - get-farmg-atorn^legs-and-deparmre-tiinesl, origin-airport, 

destination-airportl, airline) 
Let faring-atom2 - get-fermg-atom(legs-and-departure-times2, origin-airport2, 

destination-airport, airline) 
If (faring-atoml <> nil and faring-atom2 <> nil) 

online-divisions +- list(faring-fttoml, faring-atom2) 
return (online-divisions) 
For each itinerary in itineraries 
Let divisions - { {} } 

Let legs-and-departure- times = itinerary .legs-and-departure-times 



Referring now to FIG. 7, a process 88 to apply the faring 
rules to faring atoms is shown. The input to the application 
process 88 includes the fare/rules database 20a and faring 
markets 130. For each faring atom in each faring market, a 
fare and corresponding rules are retrieved 132 from fare/ 
rules database 20a. The rules are applied to the faring-atoms 
at 134. Because faring-atoms are shared across itineraries, it 
is only necessary to apply a fare's rules to a faring atom once 
no matter how many itineraries the faring-atom may appear 
in. The results of rule applications are cached 136. Caching 
of a rule minimizes computational effort. This is because the 
rule application process 88 involves many redundancies, 
because different fares share rule restrictions. Valid fare/ 
faring-atom combinations are stored 138 in the form of 
fare-components. 



Referring to FIGS. 8Aand 8B, a process 132 for retriev- 
ing rules and footnotes from the rules database 20a contain- 
ing the ATPCO rules, routes and fares includes retrieving 
150 general rules commonly referred to as record_0*s for 
each faring atom in a faring market. The retrieved general 
rules are searched 152 to find the first record_0 matched to 
the faring atom to produce a matched record_0. If there is 
a matched record__0, it is stored at 154. Whether or not there 
are matched record_0's, the process 132 retrieves 156 
application rules commonly referred to as record_l rules. 
TTie retrieved application rules are searched to find the first 
record_l matched to each of the faring atoms. The first 
matched record_l*s is stored 160. 

If after traversing through all the record_l*s there are no 
matches found, the process will return a "FAIL" at 162 and 



60 
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terminate indicating that the faring atom cannot be used by 
the faring process 18. 

If there is a match, the process 132 retrieves 164 category 
controls (commonly referred to as record^ 's). The process 
132 will find the first record-2 in each category that matches 
the fare. Record_^2's or the category control records typi- 
cally comprise a large number of categories currently 30 
different categories. The process is run for each category. It 
is not necessary that every category have a match and in 
many instances many if not most categories will not have a 
match. Rules in those categories that have a match are stored 
at 168 and the process continues to run at 170 until all 
categories have been traversed. If all categories have not 
been traversed, a pointer to a next category 172 is set and the 
next category is retrieved 164. If all categories have been 
evaluated, the process retrieves 176 linked record_3's and 
applies process 132 (FIG. 7). In this embodiment. Record - 
3's are retrieved 176 as part of the rule application process 
132. 

The ATPCO rule retrieval process 132 that retrieves the 
rules for a fare includes record-matching processes 150, 156, 
and 164 (FIG. 8A) that may depend on the departure date of 
the faring-atom. To minimize computational effort expended 
in rule retrieval 132, rules for a fare are not retrieved once 
for every faring-atom, but at most once per departure-date. 
To further minimize computation, a caching mechanism is 
employed. 

Referring now to FIG. 8C, a process that checks dates for 
rule retrieval includes retrieving 177 a current date from a 
faring market that contains faring atoms with multiple travel 
dates, and a stored date corresponding to a latest stored date 
that a result for the rule remains valid. The current date is 
compared 178 to the stored date and if the rule still remains 
valid (i.e., the current date falls within a bound set by the 
stored date) the rule is not retrieved and instead rules that 
had been cached are used. If the stored date for the rule is 
not valid then a new rule is retrieved 179 and a new date is 
subsequently stored 180 for the new rule. 

Referring now to FIG. 9, a process 134 for applying the 
rules retrieved with process 132 is shown. The rule appli- 
cation process 134 operates on each faring atom. The 
process 134 applies 181 the record-1 records to check for 
booking codes etc. The process 134 determines 182 whether 
each record-2 was cached in the faring atom. If a record-2 
was cached in the faring atom, the process returns 183 the 
cached results. Otherwise, the process 134 applies 184 the 
record _Z f s for each of the stored record_2 categories. 
Rules provisions are expressed as "record-2s", which are 
retrieved 132, as described in FIGS. 8A, 8B. These record-2s 
express logical relations over so called "record-3s", which 
are records that contain detailed provisions. Individual pro- 
cedures are provided for evaluating each record-3 as applied 
to a faring atom. Each record-3 procedure returns either 
DEFER, FAIL, PASS, NO-MATCH or UNAVAILABLE, 
and these results are combined according to the logic in the 
record-2 to produce a result of either DEFER, FAIL or PASS 
for the entire record-2. The proper procedures for applying 
record-3s and for combining their results according to 
record -2s are described in the ATPCO documentation. The 
"PASS" value is an extension used here since not all 
record-3s can be fully evaluated on the basis of the faring- 
atom alone. The RECORD-2 result is either PASS, FAIL or 
DEFER (the other two values are from record-3s). 

As a result of returning a cached result or of the appli- 
cation of the record^ 's, the process can return one of five 
possible results, "DEFER", "PASS", or "FAIL." The record 
as well as its results DEFER, PASS, or FAIL, are cached at 
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136 in the faring atom. The result FAIL causes the process 
134 to exit 190. Whereas, returning a pass or a defer permits 
the process 134 to continue to examine remaining record-2s. 
A defer or pass result is stored 185 and it is determined 186 
5 whether all record-2s have been processed If all records 
have not been applied/examined if cached (branches to NO), 
the next record-2 is retrieved at 186a. After all record-2s 
have been examined (YES at 186) and, if pass results have 
been provided for all, e.g., did not branch, the PASS result 
10 causes the process 134 to construct 187 fare components and 
exit 190. If at least one DEFER result was returned process 
134 constructs 188 the fare components, stores 189 deferred 
record-2 *s in the faring component and exits 190. The 
routines 188, 189 and 190 thus correspond to the stored valid 
15 faring atom combination routine 138 (FIG. 7). 
APPLICATION OF RECORD-3S 

The information contained in record-3s varies by cat- 
egory. For example, category-5 record -3s, which specify 
advanced-purchase restrictions, contain fields that specify 
20 how long in advance of travel time a fare must be reserved, 
how long after a reservation a fare must be purchased, and 
so on. Category -4 record-3s, which specify flight- 
restrictions, contain fields that restrict flight-numbers, 
aircraft-type, airline, and whether flights are direct or non- 
25 stop. Every category has a different procedure for evaluating 
a faring-atom. 

As discussed above the record-3 procedures that evaluate 
a faring-atom returns one of five values, and may return 
some other information such as discounts, penalties and 

30 surcharges. A value of PASS or FAIL can only be returned 
if that answer can be determined without examining any 
faring-atom other than the one the fare spans. 

The ATPCO rules distinguish between fare-component 
and priceable-unit restrictions. Most restrictions on travel 

35 route, flight-numbers, and aircraft-type are fare-component- 
based, i.e., restrict only the flights in the faring-atom gov- 
erned by the fare. On the other hand, minimum and 
maximum-stay restrictions are priceable-unit-based, i.e., 
apply to joint properties of all the faring-atoms within a 

40 priceable-unit. A minimum-stay requirement for a round-trip 
fare, for example, constrains the combination of outbound 
and return faring-atoms. Generally speaking, FC-based 
record-3s will be able to return either PASS or FAIL, while 
PU-based restrictions may need to be deferred. Deferring 

45 rules means checking them at a later point, however. This is 
a more computationally expensive process, because it must 
be done for combinations of faring-atoms within a priceable- 
unit, and the number ways faring-atoms can be combined to 
create priceable-units can be quite large, and grows quickly 

50 with the size of the priceable-unit. For this reason, whenever 
possible it is desirable for record-3 application not to result 
in a value of DEFER. 

Many properties of faring-atoms can be bounded. For 
example, the earliest and latest departure-time within a 

55 fa ring- market, or within a shoe, can be recorded, as well as 
the minimum and maximum number of connections within 
the faring-market and so forth. This information can often be 
used to evaluate priceable-unit restrictions at the fare- 
component level. A simple example of this is given below. 

60 In this example, it is assumed that a certain fare's rules 
require at least a 3-day layover at the intermediate point of 
a round-trip priceable-unit, measured from the departure- 
times of the fare-components. The fare is used for the first 
half (outbound travel) of the priceable-unit, in the NW 

65 CHI_MSP faring-market in slice 1. If there are exactly two 
slices in the query, then the fare-component that covers 
return travel must come from the NW MSP_CHI faring- 
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market in slice 2. Suppose that the following faring-atoms 
exist (TABLE 13). (The airport ORD is in the city Chicago.) 

TABLE 13 



Slice 2 NW MSP_CHI 
Slice 1 NW CHI_MSP Caring-atoms faring-atoms 

ORD_MSP NW220 12APR97 13:00 MSP_ORD NW301 15APR97 

19:00 

ORD_MSP NW220 13APR97 13:00 MSP_ORD NWS77 16APR97 

12:00 

ORD_JViSP NW220 14AFR97 13:00 MSP_ORD NW301 16APR97 

19:00 



In each faring-market, the earliest and latest departure- 
times can be calculated. In this case, the earliest departure - 
time in the slice-2 NW MSP_ORD market is 15APR97 
19:00, and the latest departure -time is 16APR97 19:00. 

When the minimum-stay requirement restriction is 
applied to the first faring-atom, its departure time of 
12APR97 13:00 can be compared to the two outer bounds on 
return-travel departure-time, 15APR97 19:00 and 16APR97 
19:00. In this case, the minimum-stay requirement is met 
even for the earliest possible return travel time, so the 
faring-atom unconditionally passes the restriction. 

Similarly, for the third faring-atom, since the restriction 
fails even for the latest possible return-travel departure-time, 
the faring-atom unconditionally fails the minimum-stay 
requirement. But for the second faring-atom, because the 
restriction fails for the earliest possible return time, but 
passes the latest possible return time, it is necessary to defer 
the application of the restriction. 
GENERAL TIME BOUNDS 

Many priceable-unit-based categories restrict times. Cat- 
egories 3, 5, 6, 7, 8, 9, 10 and 14 are usually priceable-unit- 
based. Categories 3 and 14 usually restrict the departure-date 
of the first flight in a priceable-unit. Category 5 specifies 
how far in advance of travel fares must be purchased, and 
this is usually measured from the departure-date of the first 
flight in a priceable-unit. Categories 6 and 7 specify mini- 
mum and maximum-stays at stopovers within a priceable- 
unit. 

In many cases these categories do not need to be deferred. 
This is especially true if , as in the above example, time- 
bounds are known for other faring-markets in the journey, 
and the range of faring-markets that might enter into a 
priceable-unit with the faring-atom in not great. It is a 
relatively simple matter to record for each faring-market the 
earliest and latest departure-date of any faring-atom within 
the faring-market. This can be done as faring-atoms are 
constructed. The problem remains of how to know what 
other faring-markets might participate in a priceable-unit 
with the faring-atom at hand. 
CATEGORY-3 

Pseudo code for an example of a procedure that imple- 
ments record-3 category-3, "Seasonality Restrictions" is 
shown in TABLE 15. Each category-3 record-3 an example 



'5,521 Bl 

20 

of which is shown in TABLE 14 specifies a permissible date 
range for travel, via a start -date and an end-date, either of 
which may be left blank. The default interpretation of 
category-3 is that these date restrictions apply to the 

5 departure-date of the first flight of the priceable-unit This 
interpretation can be modified in two ways. First, if a certain 
field is set, then the category becomes fare-component 
based. In other words, the date restrictions apply to the 
departure-date of the first flight within the fare-component. 

10 Second, a geographic specification may be provided that 
alters the measurement of the departure -date. For example, 
the geographic specification may dictate that the relevant 
date is the departure-date of the first transoceanic flight. 

J5 Category-3s (TABLE 14) also includes a field that speci- 
fies whether the record-3 is available. If it is not, that is an 
indication that some information is missing and the record-3 
should not be used for pricing a ticket. In this case, the 
record-3 application must return UNAVAILABLE. Finally, a 

20 category-3 may include a specification of a date range that 
the category-3 is valid for. If travel is outside of these dates, 
the record-3 application must return NO -MATCH. 
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Catcgoiy-3 field 


Example 


Earliest Permitted Travel Date 


nil 


Latest Permitted Travel Date 


190CT97 


Fare-Component Based 


false 


Geographic Specification 


nil 


Earliest Record-3 Valid Date 


15MAY88 


Latest Record- 3 Valid Date 


nil 


Available 


true 



The logic of the procedure that processes the record-3 is 

35 as follows. If the record-3 is not available, UNAVAILABLE 
is returned. If travel is outside of the valid date-range of the 
record-3, NO-MATCH is returned. Then, processing 
branches depending on whether the record-3 is priceable- 
unit based (the default), or fare-component based. If fare- 

40 component based, and there is no geographic specification, 
the departure date of the faring-atom is compared to the 
date-range of the record-3, and either PASS or FAIL is 
returned. If a geographic specification is provided, then this 
is used to compute the relevant travel date, and the same 

45 procedure applies. If, on the other hand, the record-3 is 
priceable-unit based, then broad time -bounds checks are 
used. If there is no geographic specification, the earliest and 
latest possible priceable-unit departure-dates are retrieved 
and compared to the date-range of the record-3. If they both 

50 succeed, PASS is returned. If they both fail, FAIL is 
returned. Otherwise DEFER is returned. Finally, if the 
record-3 is priceable-unit based and includes a geographic 
specification, then DEFER is returned. The following 
pseudo-code implements the processing of record-3 

55 category-3 in the case where the record-3 must be evaluated 
given only a single faring-atom from the priceable-unit. 



TABLE 15 



apply-record-3-FC-category-3(record-3, faring-atom, passenger- information, current -date) 
If (record-3. available - false) 

retum(unavailable) 
Let date - departure-date(faring-atom) 

If ((rccord-3.carlie5t-record-3-valid-date o nil and record-3 .earliest- record- 3-valid-date > date) or 
( record-3. latest-record-3-valid -date o nil and record -3. la test- record-3- valid -date < date)) 
retum(no-match)) 
If (record-3. {are-component-based = true) 
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TABLE 15 -continued 



Let travel-date = date 

If (record-3. geographic-specification o nil) 

travel-date - apply-geographic-speciriration(reOT faring-atom) 
If ((rccord-3.eariicst-permitted-travel-date o nil and record-3.earltest-penniued-travel-date > travel-date) or 
(record-3.1atest-permitted- travel-date o nil and record-3.1atest-permited-travel-date < travel-date)) 

retum(fail) 

Else 

return(pass) 

Else If (record-3.geographic-spetification o nil) 
return (defer) 

Else 

Let earliest- travel-date - carliest-priceable-unU-departure-date(faring-atom) 
Let la test-travel -date = latcst-priccablc-uriit-departiJ re-da te(£aring-a torn) 
Let result » pass 

If (record-3.earliest-permitted-travel-date o oil) 

If (record-3.eailiest-permittcd-travel-date > la test -travel -date) 
result = fail 

Else If (record-3.earlicst-penmtted-travel-date <- earliest- travel-date) 

result = defer 
If (record-3.1alest-permitted-travel-date <> nil) 

If (record -3 .latest-pennitted-travel-date < earliest-travel-date) 

result - fail 

Else If (result <> fail and record-3.1atest-permilted- travel-dale >» latest- travel-date) 
result - defer 
return (result) 



There can be another version of this application 
procedure, as shown in TABLE 16 dedicated to the case 
where all of the faring-atoms within the priceable-unit are 
known. This procedure is simpler, because there is no need 
for lime bound checks since all times are known exactly. 
This procedure is used to evaluate deferred record_3*s (see 
TABLE 24). 



the same cities but in opposite directions. The process 90 
also enumerates collections of sets of faring components at 
202. For each faring market in a collection of faring markets 
its faring components are partitioned into sets of fare com- 
ponents that have the same fare and the same combinability 
record-2s. Collections of these sets are enumerated with one 
set chosen from each faring market resulting in a collection 
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TABLE 16 



apply-record-3-PU-category-3(rccord-3, fares, faring-atoms, prime- faring-atom, passenger-information, current-date) 
If (record-3.available - false) 

return(unava liable) 
Let date - dcparturc-datc(prime-faring-atom) 

If ((record-3.earliest-record-3- valid-date <> nil and record-3.earliest-record-3-valid-date > date) or 
(record-3.1atest-record-3- valid-date o nil and record-3.Iatest-record-3- valid-date < date)) 
return(no-match)) 
Let travel-date - date 
If (record-3.fare-component-based ° true) 

If (rec»rd-3.geograpluc-specincation o nil) 

tiavei-date = appty-geographic-spc^ification(rcc^ prime- fa ring-atom) 

Else 

travel-date - departure-date (faring-atoms) 
If (record-3.geographic-specification <> nil) 

travel-date = apply-geographic-specification(record-3.g^ faring-atoms) 
If ((record-3. earliest-permitted- travel-date <> nil and record-3.earliest-permitted-traveI-date > travel-date) or 
(ircord-3. latest-pennitted-travel-date <> nil and rccord-3 la test -pennited -travel-date < travel-date)) 
return(fail) 

Else 

return (pass) 



Referring now to FIG. 10, the process 90 for constructing 
priceable units is shown. The term "priceable unit" as used 
herein represents a fundamental unit at which many fare 
restrictions apply. For example, round trip fares often 
include minimum stay requirements and these can only be 
expressed when both an outbound and a return faring atom 
are combined. This occurs at the level of the priceable unit. 

The process 90 of constructing priceable unit cores and 
pricing unit labels is organized as several nested procedures 
as follows. The process enumerates 200 a collection of 
faring markets. Collections of faring markets are enumer- 
ated 200 with each faring market from a different slice by an 
algorithm that depends on the type of a priceable unit that is 
constructed. For example, for a round trip priceable unit two 
faring markets are chosen on the same carrier and between 



of fares and associated collection of sets of fare components. 
At this juncture, any combinability record 2-s are evaluated 
to insure that the fares may be used together in a priceable 
unit. 

The process 90 also enumerates 204 collections of fare 
components. Thus, given a collection of sets of fare com- 
ponents from 202, the process evaluates any deferred record 
2-s on collections of fare components in the enumeration 
process 204. These collections are constructed by selecting 
one fare component from each set. The process of evaluating 
deferred rules on collections of fare components outputs 
results in the form of a list of factored representations of 
priceable units. Thus, the output is a logical OR of logical 
ANDs of logical ORs of fare components. 



60 
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From the factored representations produced in 204 the 
process produces priceable -unit -labels 206 and priceable- 
u nit -co res 208 with some sharing occurring between these 
structures to ensure that the number of priceable-unit-cores 
and priceable -unit- labels is kept to a minimum. 

The pseudo-code below (TABLE 17) summarizes enu- 
merating collections of faring markets process 200. It takes 
as input a set of sets of faring -markets, containing one set per 
slice. These are the faring-markets generated by the calls to 
"create -divisions," (120 FIG. 6), as described above. 



(PU-labels). PU-core data structures contain all the infor- 
mation associated with an individual priceable- unit except 
its faring-atoms. Thus, each PU-core contains a set of fares 
(one fare per fare -component in the priceable -unit) and any 
other information associated with those fares, such as 
discounts, surcharges and penalties. PU-label data structures 
compactly represent connections between faring-atoms and 
PU-cores. 

At this stage of processing, a collection of fares has been 
fixed on, and for each fare there is a set of fare-components. 



TABLE 17 



create-priceable-imits( faring- market-sets) 

Let number-of-slices - length(faring-market-sets) 

Let priceable-unit-labels = {} 

For sllce-numberl from 1 to number-of-slices 

For faring- marketl in faring- market-set^sUce-numberl] 

Let airline = faring-marketl. airline 

// Create one-way priceable-units. 

priceable-unit-labels - create-PUs-in-marketsl (faring- marketl, priceable-unit-labels, one-way) 
For slice- number2 from slice- number 1 + 1 to number-of-slices 

For faring- markel2 in fariiig-markcts-on-carrier(fariDg-rnarket-sets(slice-number2], airline) 
It Create single and double open-jaws. 

priceable-unit-labeU - create-PUs-in-markets2(fflring-markctl ( faring-marketl, 

priceable-unit-labels, open-jaw) 
If (faring- marketl .destination-city = raring- market2.origin-city) 
// Create round-trips and circle-trips of size 2. 
If (faring- market2. destination = faring-marketl. origin) 

priceable-unit-labels = create- PUs-in-markets2(faring- marketl, faring-market2, 

priceable-unit-labels, round-trip) 
priceable-unit-labels » create- PUs-in-markets2(raring-marketl, faring-market2, 
priceable-unit-labels, circle -Lrip2) 
For sliee-number3 from slice-number2 + 1 to number-of-slices 

For faring-market3 in faring- markets-on-caiTicr(fa ring-market-setsl slice- numbcr3], airline) 
If (faring-market2.destination-city « fering-market3. origin-city) 
// Create circle- trips of size 3. 

If (faring-markcO. destination-city = faring-marketl .origin-city) 
priceable-unit-labels = 

create-PUs-m-markete3(£armg-marketl, faring-market2, faring- 

// 

// More iterations for circle-trips of lengths 4 and 5. 
// 

// Store priceable-unit-labels in faring-atoms. 
For priceable-unit-label in priceable-unit-labels 

For faring-atom-set in priceable-unit-label.faring-atom-sets 
For faring- a lorn in faring-atom-set 

faring- atom, priceable-unit-labels +— priceable-unit-label 



This pseudo-code iterates over faring-markets in different 45 
slices, and passes faring markets to one of several possible 
create-PUs-in-markets procedures. These procedures vary 
by size of priceable-unit produced. The code ensures that the 
faring-markets are in the correct format for the type of 
priceable-unit produced, and that the priceable units are all 
on the same airline. This last restriction is motivated by 50 
efficiency since rarely do carriers permit priceable-units with 
fares from more than one airline. 

Each call to create-PUs-in-markets returns an updated set 
of priceable-unit-labels. At the end of the procedure, these 
priceable-unit-labels are stored in their component faring- 55 
atoms. 

There are many other combinability restrictions that limit 
the manner in which fare components can be combined into 
priceable continuous units. Even when searching for fares 
for a small number of itineraries, there can be a very large 
number of possible pricing units because of the large number 60 
of possible fares that can exist. It is preferred to represent 
these priceable units in a compact manner so as to minimize 
the computation involved in their construction. 

The faring algorithm does not actually construct a data- 
structure for every priceable-unit. Instead, priceable-units 65 
are represented by a combination of two data structures: 
priceable-unit-cores (PU-cores) and priceable-unit-labels 



Priceable-units are constructed by selecting one fare- 
component from each set and evaluating any deferred rules. 
The simplest manner that this could be accomplished would 
be to enumerate complete collections of fare-components 
and to apply the deferred record-2s from within these 
fare-components. Often, this method can be made more 
efficient ui some cases by use of the function get-OR-AND- 
OR-fortn as will be described. That function takes a collec- 
tion of sets of fare-components, evaluates any deferred 
rule-conditions, and returns a representation of the set of 
valid priceable-units. This representation is in OR-AND-OR 
form. In other words, it takes the form of a set of collections 
of sets of fare-components. This is very close to a set of 
priceable-unit-labels except that since the sets are of fare- 
components rather than faring-atoms, there are no PU-cores. 
The inner sets of fare-components returned by get-OR- 
AND-OR-form are guaranteed to have the same fares, 
surcharges, discounts, penalties and so on. 

PU-cores and PU-labels are constructed from the output 
of get-OR-AND-OR. The pseudo-code below summarizes 
this procedure. It iterates over the inner AND- OR form, 
constructing PU-cores (if no identical PU-core already 
exists) and PU-labels (if no identical PU-label already 
exists). PU-labels are constructed by mapping from fare- 
components to faring-atoms. PU-cores are stored on 
PU-labels. 
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creau;-PUs-froin-Carc-compone[iLs(f a ring- markets, fores, fare-componem-sets, existfng-PU- labels, 
environmental-information) 

Let slice- numbers - {} 

Lei PU-labels » existing- PU- labels 

Let PU -cores = {} 

For faring- market in faring- markets 

slice-numbers +*> faring-markctslicc-aumbcr 
For AND-OR in get-OR-AM>OR(fariag-markets, fare-component-sets, envircnraental-information) 

// 

// AND-OR is a collection of sets of fare-components, representing all the priceablc-units 

// that can be constructed by choosing one fare-component from each set. 

// 

Let PU-corc - nil 

Let surcharges = {} 

Let faring-atom-sets - {} 

For fare-componcnt-set in AND-OR 

surcharges += flrst(fare-component-set).surcharges 

Let faring-atom-Get - {} 

For fare-component in fare-component-set 

faring-alom-set +*■ fere-oomponent.f a ring-atom 

faring-atom-sets +- faring-atom-set 
// Find aa existing PU-core with these fares and surcharges, or construct a new one. 
For test-PU-core in PU-cores 

If (test-PU-core.surcharges - surcharges) 
PU-core - test-PU-core 
If (PU-core - ml) 

PU-core = new-PU-core( ) 

PU-corc. fares - fares 

PU-core.surcharges = surcharges 

PU-core. slice -numbers = slice- numbers 
// Find an existing PU-label with these faring-atoms, or construct a new one. 
Let PU-label - nil 
For test-PU-label in PU-labels 

If (test-PU-label. faring-atom-sets - faring-atom-sets) 
PU-labcI = test-PU-label 
If (PU-label = nil) 

PU-label - new-PU-label( ) 

PU-label.faring-atom-scts = faring-atom-sets 

PU-label.slice-numbers = slice-numbers 

PU-label.priceable-unit-cores - {} 

PU-labcls += PU-label 
PU-label.priceabIe-unit-oores += PU-core 
return(PU-labels) 



To understand the role PU-cores and PU-labels play in the 
faxing algorithm, it may be helpful to look at an example, 
involving a round-trip journey between BOS and MSP. In 
this example, there arc four outbound itineraries and four 
return itineraries, each of which is spanned by a single 
faring-market. 

For both the outbound and return itineraries, there is a 
choice between two airlines, UA and NW. Both of these 
airlines offer two round-trip fares and one one-way fare. 
This situation is summarized in TABLE 19 below. 

TABLE 19 



40 



Fa ring- market Faring- Atoms 



Fares 



Slice 1: UA 
BOS— MSP 



Slice 1:NW 
BOS-MSP 



Slice 2: 



BOS— MSP UA100 
BOS— MSP UA200 



UA BOS-MSP RT "Q" 
UA BOS-MSP RT "Ml 4** 
UA BOS-MSP OW "Y" 
BOS-MSP NW300 NW BOS-MSP RT "HE7" 
BOS-MSP NW400 NW BOS-MSP RT "Q7NR" 

NW BOS-MSP OW "F' 
MSP— BOS UA111 same as for the outbound 
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TABLE 19-continued 



Faring-market 


Faring-Atoms 


Fares 


UA MSP— BOS 


MSP— BOS UA222 


UA faring-market 


Slice 2: 


MSP— BOS NW333 


same as for the outbound 


NW MSP— BOS 


MSP— BOS NW444 


NW faring-market 



Assume that in each of the four faring-markets (i.e., 
50 BOS-MSP UA, BOS-MSP NW, MSP-BOS UA and MSP- 
BOS NW), fare-components have been constructed for 
every combination of faring-atom and fare. The fare- 
components built from the fare "NW BOS-MSP RT HE7' 
contain a deferred record-2 that is checked during priceable- 
unit construction. This record-2 does not permit outbound 
travel on flight "NW300" combined with return travel on 
flight "NW444.*' When constructing round-trip priceable- 
units, round-trip fares are combined with like round-trip 
fares. This situation permits the construction of a total of 23 
priceable-units, as shown in TABLE 20. 
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TABLE 20 



Priceable-Unit 

Number nnd Slice- 1 Faring- Slice- 1 Slice-2 Slice-2 

Type Atom Fare Faring-Atom Fare 



1 Round-trip 

2 Round-trip 

3 Round-trip 

4 Round-trip 

5 Round-trip 

6 Round-trip 

7 Round-trip 

8 Round-trip 

9 Round-trip 

10 Round-trip 

11 Round-trip 

12 Round-trip 

13 Round- trip 

14 Round-trip 

15 One-way 

16 One-way 

17 One-way 

18 One-way 

19 One-way 

20 One-way 

21 One-way 

22 One-way 

23 One-way 



BOS- 
BOS- 
BOS- 
BOS- 
BOS- 
BOS- 
BOS- 
BOS- 
BOS- 
BOS- 
BOS- 
BOS- 
BOS- 
BOS- 
BOS- 
BOS- 
BOS- 
BOS- 
BOS- 



>MSP UA100 
■MSP UA100 
-MSP UA100 
-MSP UA100 
-MSP UA200 
-MSP UA200 
-MSP UA200 
•MSP UA200 
-MSP NW300 
•MSP NW300 
•MSP NW300 
•MSP NW400 
•MSP NW400 
MSP NW400 
•MSP NW400 
•MSP UA100 
MSP UA200 
•MSP NW300 
•MSP NW400 



RT-Q" 
RT "Ml 4" 
RT"Q" 
RT "Ml 4" 
RT "O" 
FT "Ml 4" 
RT "Q" 
RT "Ml 4" 
RT "HE7NR" 
RT -Q7NR" 
RT "Q7NR" 
RT "HE7NR" 
RT "Q7NR" 
RT "HE7NR" 
RT "Q7NR" 
OWV 
OWT 
OW "F' 
OW "P* 



MSP-BOS UA111 RT 
MSP-BOS UA111 RT 
MSP-BOS UA222 RT 
MSP-BOS UA222 RT 
MSP-BOS UA111 RT 
MSP-BOS UA111 RT 
MSP-BOS UA222 RT 
MSP-BOS UA222 RT 
MSP-BOS NW333 RT 
MSP-BOS NW333 RT 
MSP-BOS NW444 RT 
MSP-BOS NW333 RT 
MSP-BOS NW333 RT 
MSP-BOS NW444 RT 
MSP-BOS NW444 RT 



"Q" 

•M14" 

"Q" 

"M14" 

«Q" 

*M14" 

"Q" 

"M14" 

"HE7" 

-Q7NR" 

"Q7NR" 

"HE7" 

"Q7NR" 

-Q7NR" 



MSP-BOS UAlll OW "Y" 
MSP-BOS UA222 OW "Y" 
MSP-BOS NW333 OW "F* 
MSP— BOS NW444 OW "F* 



Even in this example, the list of possible priceable-units 
is long (23 units). The reason that there are so many 
priceable-units is because production of priceable-units 30 
involves several choices (of fares and faring-atoms). 

In TABLE 21 below, each entry represents a choice (an 
OR) of either faring-atoms or PU -cores. Each row represents 
a collection (an AND) of these choices. And finally, the 
entire table represents a choice (an OR) over these collec- 35 
tions. Collectively, this OR-AND-OR table provides a com- 
pact representation of the 23 priceable-units. 

TABLE 21 



Label SIice-1 Faring-Atom Slicc-2 Faring-Atom Priceable-Unit-Cbre 
Number Options Options Options 

1 BOS— MSP UA100 
BOS— MSP UA200 

2 BOS— MSP NW300 
BOS— MSP NW400 

3 BOS— MSP NW300 

4 BOS— MSP NW400 

5 BOS— MSP UA100 
BOS— MSP UA200 

6 BOS— MSP NW300 
BOS— MSP NW400 

7 
8 



units. PU-label #1, for example, represents a total of eight 
different priceable-units. In cases where there are interac- 
tions between the faring-atoms in different slices, several 
PU-labels can be produced for a single PU-core. An example 
of several PU-labels is shown for the NW RT "HE7" fare 
represented by PU-labels numbers 3 and 4. These priceable- 
unit-labels and priceable-unit-cores are used by the linking 
procedure 94 (FIG. 4B) to associate itineraries from more 
than one slice to fares. 



MSP-BOS UAlll 1: RT "Q", 2: RT "Q" 

MSP-BOS UA222 1: RT "M14'\ 2: RT "M14" 

MSP-BOS NW333 1: RT "Q7NR'\ 2: RT "Q7NR" 
MSP-BOS NW444 

MSP-BOS NW333 1: RT "HE7", 2: RT "HE7' 

MSP-BOS NW333 1 : RT "HE7", 2: RT "HE7" 
MSP— BOS NW444 

1: OW "Y" 
1: OW "F* 

MSP-BOS UAlll 2: OW "Y" 
MSP-BOS UA222 

MSP-BOS NW333 2: OW "F" 
MSP-BOS NW444 



Each row of TABLE 21 is a priceable-unit-label (PU- 
label), an object that factors a set of priceable-units into a 6Q 
collection of choices that have no further dependencies. 
There is a choice for every faring-atom involved in the 
priceable-unit, and a choice of a priceable-unit-core (PU- 
core). Each PU-core contains the same number of fares as 
there are faring-atom choices. In the case where there are no 65 
constraints between faring-atoms in different slices, 
PU-labels are a very compact representation of priceable- 



ENUMERATING COLLECTIONS OF SETS OF FARE- 
COMPONENTS 

Each of the faring-markets that is passed to create-PUs- 
in-markets has a set of fare-components produced by apply- 
ing fare rules procedure 88. 

Referring now to FIG. 10A, enumerating collections of 
sets of fare-components 202 (described by pseudo-code 
below) partitions the fare-components in each faring-market 
into sets such that every fare-component in a set has the 
same fare and the same combin ability record -2s. Fare com- 
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binability restrictions are specified in record -2s rule category 
10. Any category- 10 record-2s in a fare's rules is stored in 
the combinability-record-2 field in the fare-components. 

Once fare-components are partitioned 202a into sets, 
collections of these sets are enumerated 2026, by selecting 
one set from each faring-market. For each fare there is a 
choice of fare-components. At this point, when the fares 
within a priceable-unit have been fixed, any category- 10 
record-2s that was deferred is applied 202c to determine 
whether the fares may be used together in a priceable-unit. 
This is accomplished by applying 202c each fare's comb in- 
ability record-2 (if it has one) to every other fare within the 
priceable-unit 

The code below (TABLE 22) is written for two faring- 
markets within a priceable-unit, as would be the case fbr 
round-trips, open jaws and circle-trips of size two. Similar 
code would be used for priceable-units of other sizes. 
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Referring now to FIG. U, a process 204 to enumerate 
collection of fare components is shown. The process 204 can 
enumerate 212 a collection of sets of fare-components, 
enumerate 214 fare components by selecting one component 

5 from each set, apply or evaluate 216 any deferred rule- 
conditions, and return a compact representation 218 of the 
set of valid priceable-units. A preferred technique to accom- 
plish this uses a "GET_OR_AND_OR" operation 
described below TABLES 24 , 26 and 27. 

The representation process 218 produces an OR-AND- 

10 OR representation of the priceable units. The process 218 
produces a set of collections of sets of fare-components 
similar to that in FIG. 20, that will later be transformed into 
priceable-unit-labels and priceable-unit-cores by processes 
206 and 208 described further in TABLE 22. The inner sets 

15 of fare -components returned by get-OR-AND-OR-form 
have the same fares, surcharges, discounts, penalties and so 
on. 



TABLE 22 



partitioii-farc-components- into-scts(faring- market) 
// 

// Partition fare-components into sets based on fare and combinability record-2. 
// 

Let fare-component-sets « {} 

For fare-component in faring- rnarkeLfare-components 
Let fare - fare-componcnt.fare 

Let combinability-record-2 « fare-component.combinabUity- record-2 

Let previous-set « nil 

For test-set in fare-component-sets 

Let test-fare-component » firs t( test-set) 
If ((fare = test-faie-componenLfare) and 

(combinability-record-2 - test-fere-componentcombinability-rea)rd-2)) 
previsous-set « test-set 
If (previous-set - nil) 

fare-component-sets +- list(fare-component) 

Else 

previous-set += fare-component 
return(fare-component-sets) 

crcate-PUs-in- markets 2( fori rig-marketl , faring- market2, existing- PU-labels, PU-type, environmental-information) 
Let fare-component-setsl = partiUon-fare-components-into-seU(faring-marketl) 
Let fare-component-sets2 - partition-fare-components-bU>&cts(farirg-market2.) 
Let PU-iabels = existing- PU-labels 
For fare-componentsl in fare-component-setsl 

For fare-components2 in fare-component-sets2 
Let fare! = flrst(fare-componentsl).fare 
Let fare2 « Mrst(fare-components2).fare 

Let combinability-record-2-1 - first(fare-componentsl). combinability- record-2 
Let comb inability- record -2- 2 = first(fare-components2). combinability- record-2 
// Check fare combinability requirements, by applying each fares 's combinability 
// record-2 to all the other fares within the priceable-unit 
If ((combinability-record-2-1 - nil or 

ar^ly-combmabu^ty-record-2(combuiability-record-2-l, fare2, PU-type) « pass) and 

(combinability- record- 2-2 - nil or 

arjply-combmabiJity-record-2(combinability-record-2-2, fare 3, PU-type) - pass)) 
PU-labels « create-PUs-from-fare-comrx)nents(liRt(faring-markea, faring-market2). 

tistfforel, fare2), 

list(fare-compooentsl, fare-oomponcnts2), 
PU-labels, environmental-information) 

return(PU-labels) 



The procedure create-PUs-in-markets2, after it has 
selected two fares and two sets of fare -components and 
verified fare combinability restrictions, calls the procedure 
2&2d create-PUs-from -fare-components to evaluate deferred 
rules and construct priceable-unit-labels and priceable-unit- 60 
cores. 

CONSTRUCTING PRICEABLE-UNITS 

At this stage of processing, a collection of fares is 
determined, and for each fare there is a set of fare- 
components. Priceable-units are constructed by selecting 65 
one fare-component from each set and evaluating any 
deferred rules. 



The procedure 218 get-OR-AND-OR, takes a collection 
of fare -component sets and enumerate collections of fare- 
components by selecting one from each set. It evaluates any 
deferred record-2s, and constructs a set of valid priceable- 
units. This set is transformed into a factored OR-AND-OR 
form, and returned. 

Referring back to FIG. 10, PU-cores and PU-labels are 
constructed 210 at process 206 and 208 from the output of 
get-OR-AND-OR process 204. The pseudo-code below and 
FIGS. 12-13 summarizes this procedure. Construction 210 
iterates over the inner AND-OR form, producing PU-cores 
206 (if no identical PU-core already exists) and PU-labels 
208 (if no identical PU-label already exists). PU-labels are 
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produced by mapping fare-components to faring-atoms and 
PU-cores are stored on PU-labels. 
FACTORING PRICEABLE-UNITS 

Referring now to FIGS. 12-15, the get-OR-AND-OR 
process 218 to construct the priceable unit representation is 
shown and is also described in detail below through pseudo- 
code. As shown in FIG. 12 and in pseudo-code in TABLE 23 
below, three different high-level procedures are used, 
depending on whether priceable-units are one 220, two 222, 
or three or more 224 fa re -components. 
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TABLE 25 



FACTORING PRICEABLE-UNITS OF SEE ONE 

paitition-farfr-componecU-by-6urchaiges(£are-compoaents) 
Let partitions = {} 

For fare-component in fare-components 
Let found-partition - false 
Let surcharges - fare-componenLsurcharges 



TABLE 23 



get-OR-AND-OR(faring-markets > fare-compcnent-seU, environmental-information) 
Let size « lcngth(faring-markcLs) 
If (size - 1) 

return(get-OR-AND-OR*l(faring-markets, fare-component-sets, environmental- information) 
Else If (size - 2) 

rctura(get-OR-AND-OR-2(fa ring-markets, fare-component-sets, environmental- information) 

Else 

rct4irn(gct-OR-AND-OR-3+(faririg- markets, fare-component-sets, environmental-information) 



Two auxiliary functions are used in the get-OR-AND-OR 
procedures. The first, apply-deferred-record-2s 218a, takes a 
collection of fare-components (a potential priceable-unit) 
and evaluates any deferred record-2s they might have. In 
contrast to the initial stage of rule application, here all the 
fares and faring-atoms within the priceable-unit are known. 
It returns either PASS, FAIL or DEFER (in this case, 
DEFER means that the record-2s cannot be evaluated even 
at the priceable-unit level: they involve journey-level 
constraints). In such a case the priceable-unit is not produced 
(TABLE 24.) 

TABLE 24 

apply-deferred-record-2s(fere-components, en viro nmenta 1- info r matio n) 
Let faring-atoms - {} 
Let fares - {} 

For fare-component in fare-components 
fares +- fare-componenLfare 
faring-atoms +« fare-compoaenUfa ring-atom 
For fare-component in fare-components 

For record- 2 in fare-componenLdeferred-record-2s 

If (apply- record-2-PU(record-2, fares, faring-atoms, 
fereKX)rnponentfering-atom, 
environmental-information) 

<> pass 
retura(fail) 

return (pass) 



The second auxiliary function, partition-fare-components- 
by-surcharges 218b, (TABLE 25) takes a set of fare- 
components and partitions it into subsets that have the same 
secondary characteristics: the same surcharges, discounts, 
penalties, etc. 



TABLE 25-continued 
25 

FACTORING PRICEABLE-UNTTS OF SIZE ONE 

For partition in partitions 
30 If (first(partition).surcharges » surcharges) 

found-partition - true 
partition +«* fere-component 
If (found-partition - false) 
35 partitions += list(fare-component) 

re turn (partitions) 



40 Referring now to FIG. 13, the get-OR-AND-OR function 
230 for priceable-units of one fare-component (one-way 
priceable-units) is shown. It is passed only a single fare- 
component set 232, and applies 216 deferred record-2s. The 

45 final set of valid fare -components is partitioned 234 into sets 
with the same surcharges, penalties, and discounts. The 
partitioned sets 236 are placed into the proper OR-AND-OR 
representation 238 to represent them in a compact form. 

50 

The procedure PU-1 for a priceable unit of size 1 is set out 
in TABLE 26. 



TABLE 26 



get-OR-AND-OR-1 (faring- markets, fare-component-sets, environmental-information) 
Let valid-fere-components - {} 
For fere-component in first(ferc-component-sets) 

If (apply-aeferred-record-2s(list(fare-component), environmental-information) 
valid- fere-components +» fare-component 
Let OR-AND-OR - {} 

For OR in rjajtition-fai^c^nTpOTeriis -by-surcharges 

Let AND-OR = list(OR) 

OR-AND-OR +- AND-OR 
retura(OR-AND-OR) 
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FACTORING PRICEABLE-UNTTS OF SIZE TWO for evaluation of deferred record-2s. The resulting set of 

n c . *a * i* priceable-units is also represented m a compact OR-AM)- 

Refernng to FIG. 14, two-component pnceable-units ^ R r r 

include round-trips and two-component open-jaws and pse J Q ^ fof ^ get . 0 R-AND-OR-2 procedure is set 

circle-trips. They are common and should be computed 5 forlh bclow (TABLE 27). The process 240 enumerates 

efficiently and represented compactly. The function get-OR- priceable units 248 by selecting one fare component from 

AND-OR-2 240 efficiently computes and represents two each set. The get-OR-AlW-OR-2 process 240 tests deferred 

component priceable units (actions 242-246). Combinations record-2s and, if the test is passed, adds the resulting valid 

of fare-components are not enumerated unless it is necessary priceable unit to the OR-AND-OR representation. 



TABLE 27 



get-OR- AND-OR-2(fiaring-markets, Care-component-sets, environmerual-infonnation) 
Let OR-AND-OR - {} 

Subroutine fmd- AND-OR(s uncharges 1, fare-component-seQ) 
// 

// Return any AND-OR from OR-AND-OR that has fare-components with surcharges surchargesl in its 
// first set of fare-components, and has fare-component-set2 as its second set of fare-components. 
// 

For AND-OR in OR-AND-OR 

If (first(first(AND-OR)).surcharges = surchargesl and second (AND-OR) = fare-oomponenl-set2) 
return(AND-OR) 
rctura(nil) 

Subroutine add-unifonn-cross-product(fare-coinpoDent-setl, &re-oomponent-set2) 
// 

// Add the priceable-units that can be had by selecting one element from fare-component -sctl and 
// one element from fare-component-set2. Both sets are uniform with respect to surcharges. 
// 

Let AND-OR - flnd-AND-OR(first(fare-component-setl).surchflrges t fare-component-set2) 
If (AND-OR - ail) 

OR-AND-OR += list(fare-component-setl, fare-companent-set2) 

Else 

firs t( AND-OR) = append(first(AND-OR), fa re-component- set 1) 
Subroutine add-cross-product(fare-component-6etl, fare-component-set2) 
// 

// Add the priceable-units that can be had by selecting one element from fare-component-seLl and 

// one element from fare-component-set2. 

// 

Let unifonn-fare-component-setsl » partirior>fare-componenU-by-surcharges(fare-oomponent-setl) 
Let uniform-fare-component-sets2 = partirioi>fare-componenU-by-surcharges(rare-component-set2) 
For uniform- fare-component-setl in unifonn-fare-component-setsl 

For uniform- farc-component-set2 in unifonn-farc-compoacnt-scts2 

add-uniform-cross-product(unifom-fare-component-5etl , uniform- Eare-component-set2) 
Subroutine enumerate-priceable-unitsffare-componcnt-setl, fare~coinponent-set2) 
// 

// Enumerate priceable-units by selecting one fare-component from each set. Test deferred record-2s, 

// and if they pass, add the resulting priceable-unit to the OR-AND-OR representation. 

// 

For fare-componentl in fare-component-setl 
Let valid- fare-components 2 - {} 
For fare-component2 in fare-component-set2 

If (apply-deferred -re co rd-2s(list( fare -component!, fa re -co mponent2) , envirorunental-information)) 
valid-fare-components2 +— fare-component2 
If (valid-fare-components2 o {}) 

add<ross-productOist(fare-componentl), valid-fare-componenls2) 
Let fare-component-setl -with-rules - {} 
Let fare-component-setl -wimout- rules - {} 
Let tare-component-set2-with- rules = {} 
Let fare- componenL-set2- without- rules = {} 
For fare-componentl in first (fare-component-sets) 

If (fare-componentl. deferred-record-2s = nQ) 

fa re -co mpone nt-set 1 - withou t- ru les += fare-componentl 

Else 

fere-co mpone nt-setl-with-rules += fare-componentl 
For fare-component2 in second(tare-component-sets) 
If (fare-oomponent2.deferred-record-2s - nil) 

fere-component-s€t2-without-rules +■= fare-component2 

Else 

fare-component-sct2-with- rules +- fare-component2 
// There is no need to enumerate combinations of fare-components that have no deferred rules. 
add-cross-product(fare-component-setl -without- rules, fare-component-s£t2-without-rules) 
// For the remainder of fare-components, though, explicit enumeration is necessary. 
cnumeratc-priccablc-units(farc-compoacnt-sctl -with-rulcs, farc-componcnt-sct2-without-rulcs) 
enumerate-priceabievunils(fare-component-setl , fare-component-set2-with-rules) 
return(OR-AND-OR) 
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FACTORING PRICEABLE-UNITS OF SIZE THREE OR 
GREATER 

Properly enumerating all possible combinations of fare- 
components for priceable-units of size three or greater is 
computationally burdensome, though possible. 

Referring now to FIG. 15, a preferred procedure 260 finds 
a subset of possible priceable -units. In particular, it extracts 
262 those fare-components that have no deferred record-2s, 
and build priceable-units from them. Since there are no 
deferred record -2s, there are no intra-priceable-unit con- 
straints and it is possible to construct a factored represen- 
tation. 
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The procedure 268 that factors priceable-units of size three 
or greater, get-OR-AND-OR-3+, (TABLE 29) applies 
reevaluate-deferred-record-2s to each set of fare- 
components, to filter them. It then partitions the resulting 
sets based on surcharges, and takes the cross-product of 
these sets to construct the proper OR-AND-OR representa- 
tion. The procedure for the last case does not return all 
possible valid priceable-units. 
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TABLE 29 



gct-OR-ANI>OR-3+( faring-markets, fare- component-sets, environmental-information) 
Let-OR-AND-OR={ {} } 
For fere-component-set in fare-component-seU 

Let valid-fare-componcnts = reevaluatc^fcrrcd-rcccnrd-2s(fering-inarkct5, farc-componcnt-set, 

environmental -information) 

Let new-OR-ANT>OR - {} 
For OR in partition- fare-comrxinents-by-sui^^ 
For previous- AND-OR in OR-AND-OR 

new-OR-AND-OR +- postpend(previous-AND-OR, OR) 
OR-AND-OR - nc^OR-AND-OR 
return(OR-AND-OR) 



Priceable-units of size three or greater tend to have more 
deferred record-2s. This may somewhat reduce the effec- 
tiveness of the extracting procedure 262. The prevalence of 
deferred record- 2s rules occurs because in complicated 
journeys, time-bounds used in an initial rule application tend 
to be broadly specified. 

At this stage of processing time bound ranges can be 
tightened, because the faring-markets that comprise the 
priceable-unit are known. Therefore, deferred record -2s can 
be reapplied 264 to faring-atoms in the same manner that 
they are applied in the initial rule application. If all deferred 
record-2s pass, then the faring-atom is retained 266. If a 
record-2 fails or is deferred, the faring-atom is discarded. 
The function reevaluate -de ferred-record-2s (TABLE 28) 
performs this filtering. It takes a set of faring-markets and a 
fare-component set, and sets time-bounds based on the 
faring-markets. It reevaluates deferred record- 2s for each 
fare-component in the set, and returns the set of fare- 
components that have all their record-2s pass. 



LINKING ITINERARIES 

Priceable -units-labels associate faring-atoms from one or 
more slices with fares. In the pricing-graph representation 
39 set of pricing solutions, sets of priceable-unit-labels are 
used to link itineraries from different slices. 

The pricing graph representation 38* of pricing-solutions 
38 is constructed by selecting a set of priceable-unit-labels. 
Each of these PU-labels may or may not project onto a given 
slice of a journey. For example, in a round-trip journey a 
round-trip priceable-unit-label will project onto both slices, 
while a one-way priceable-unit-label will project onto only 
one slice of the journey. Once a set of PU-labels has been 
chosen, in any slice any itinerary may be chosen so long as 
it has some division that has faring-atoms containing exactly 
the PU-labels that project onto that slice. The choice of 
itinerary is otherwise independent of choices made in other 
slices. 

A set of PU-labels encodes all constraints that exist 
between itineraries in different slices. This leads to a rela- 
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TABLE 28 



reevaluatc-deferred-record-2s(fering- markets, farc-component-set, environmental-information) 
set- time- bounds (Caring- markets) 
Let fere-components - {} 
For fare-component in fare-component-sct 
Let result = pass 
Let deferred- record-2s - {} 
For record-2 in fare-component.dcferred-record-2s 
Let record-2-result, record-2-suicharges - 

apply-record-2-FC(reoord-2, fare -component far in g-atom, environmental- information) 
If (rccord-2-resuIt - pass) 

fare-componenuurcharges += rccord-2-surcharges 
Else tf (record-2-result « defer) 
deferred-record-2s -t— record-2 

Else 

result = fail 
If (result - pass) 

fare-co mpo neat-deferred- record-2s = deferred-record-2s 
fore-components +— 6a re- component 
retnra(f a re-components) 
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tively simple procedure for constructing the pricing-graph. 
Itineraries within each slice are indexed by the sets of 
multi-slice PU-labels they can be associated with. These 
indices are called slice-label-sets, and act as a logical OR 
over itineraries. The slice-label-sets from different slices are 
linked by matching PU-labels. 

Single-slice (one-way) priceable -unit-labels are treated 
somewhat differently than multi-slice priceable-unit-labels 
to enhance efficiency. In particular, there is no need to 
include single-slice PU-labels in slice-label-sets, because 
they do not need to be matched across slices. Rather, 
single-slice PU-labels are attached closely to itineraries in 
the pricing-graph. That is, within a slice-label-set, each 
itinerary is associated with a compact representation of the 
set of single-slice PU-labels that can be used with the 
itinerary, given that the multi-slice PU-labels found within 
the slice-label-set are also used. 

The linking process constructs slice-label-sets with each 
slice-label-set being a set of multi-slice PU-labels and 
associated itinerary divisions. Slice-label-sets group itiner- 
aries by multi-slice PU-labels. Each division has associated 
with it a set' of single-slice PU-labels. 

In the pricing-graph, si ice -label -sets act as ORs over 
itineraries. Multi-slice PU-labels encapsulate information 
concerning the itinerary to permit the linking process to 
operate over slice-label-sets rather than individual itinerar- 
ies. This approval is computationally efficient and results in 
small pricing-graphs. In each slice-label-set, each itinerary 
(division) is paired with a set of single-slice PU-labels. 
During construction of the pricing graph, each slice-label-set 
is transformed into an OR over ANDs of itineraries and sets 
of PU-labels. 

The linking process 282 also connects or links slice-label- 
sets from different slices, as shown in FIG. 16. Connecting 
is accomplished by starting from the first slice and working 
forward to the last slice. Intermediate results are summarized 
in open-label-sets. Each open-label-set is a set of (multi- 
slice) PU-labels that project onto slices that have not been 
processed, along with a set of backward-links that are each 
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a pair of a slice -label-set and an open-label-set from the 
previous slice. Processing starts retrieving 283 si ice- 1 and 
matching with a single, empty slice-0 open-label-set 288. 
Slice-label-sets from slice 1 are "added" 290 to this open- 
label-set, resulting in new slice-1 open-label-sets. Then 
slice -label -sets from slice -2 are added to these, resulting in 
slice -2 open-label-sets, and so on. As this process continues, 
PU-labels that are complete 293 (i.e., that do not project to 
subsequent slices) are removed 293 from open-label-sets. If 
PU labels are not complete, the index of the shoe is 
incremented 294 and the next slice is retrieved 287. If any 
pricing-solutions exist, the process will terminate 299 in a 
single, empty, last-slice open-label-set determined at 291. At 
that point, the backward-links serve as the top-level repre- 
sentation of the pricing-graph. 

Set forth below is an example of the linking process. This 
example assumes a three-slice circle-trip journey, from BOS 
to MSP to MIA. In the following discussion, PU-labels are 
identified by a unique letter followed by a sequence of digits 
that indicate which slices the PU-label projects onto. For 
example, A-23 is a two-component PU-label that projects 
onto the second and third slices. Each itinerary may have 
several divisions, and each division may have many possible 
collections of PU-labels (with each collection built by 
selecting one PU-label per faring-atom in the division). 

At this stage of processing in the faring process 18 
divisions have been produced for each itinerary, each divi- 
sion comprising a set of faring-atoms. PU-labels have been 
constructed, and stored in each faring-atom. From this 
information it is possible to enumerate for every division, 
possible collections of PU-labels, by selecting one for each 
faring-atom. TABLE 30 below summarizes the result of this 
procedure, for the example journey. Each possible collection 
of PU-labels is partitioned into those that project onto only 
one slice (one-way priceable-units) and those that project 
onto more than one-slice. In this table, divisions are encoded 
using the endpoints of faring-atoms, to save space, and each 
itinerary and division are given numeric labels so that they 
can be referenced in the rest of the discussion. 



TABLE 30 



Slice Itinerary 



Division 



1 1.1 BOS— MSP UA123 1.1.1 BOS— MSP 

1 1.2 BOS—CHI NW315 CHI MSP UA739 1.2.1 BOS— MSP; OH-MSP 



1 13 BOS— MSP CO450 

2 2.1 MSP— MIA UA901 



1.3.1 BOS— MSP 
2.1.1 MSP— MIA 



2 2.2 MSP— CBI UA623 CHI MIA UA841 2.2.3 MSP— MIA 

2.2.2 MSP— CHI; CHI— MIA 



2 23 MSP— MIA FL207 2.3.1 MSP— MIA 

3 3.1 MIA— BOS UA312 3.1.1 MIA— BOS 

3 3.2 MIA— CHI UA487 CHI-BOS NW316 3.2.1 MIA— CHI; CHI— BOS 



3 33 MIA— MSP FL208 MSP- BOS UA558 3.3.1 MIA— MSP; MSP-BOS 



Multi-Slice 


Single-Slice 


PLJ-Labels 


PU-Labels 


{A-123} 




{F-13} 


w 


{} 


{1-1} 


{B-13 C-12} 


{} 


{B-13} 


{H-l} 


{C-12} 


{0-1} 


{} 


{G-l H-l} 


{} 


{M} 


{A-123} 


{} 


{} 




{A-123} 


ft* 


{} 


{K-2} 


{C-12 D-23} 


{} 


{C-12} 


{M-2} 


{D-23} 


{1-2} 


{} 


{U2 M-2} 


{E-23} 


{} 


{A-123} 


{} 


{D-23 B-13} 


{} 


{D-23} 


{0-3} 


{B-13} 


{N-3} 


{} 


{N-3 0-3} 


{E23F13} 




{E23} 
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As TABLE 30 above shows, there are three different 
itineraries for each slice. Each itinerary is split into one or 
two divisions of faring-atoms. Each division has one or 
several possible PU-label combinations. For example, for 
the second division of the second slice-2 itinerary (22.2) 5 
there are four different PU-label sets. This is because the 
division has two faring-atoms, and each faring-atom has two 
possible PU-labels. For reference, the table below lists each 
hypothetical PU-label along with its faring-markets. 



TABLE 31 



Name 








Faring- Markets 




Comment 


A-123 


1: 


UABOS^MSP 


2: 


UA MSP— MIA 


3: UA MIA— BOS 


3 -Component Circle Trip 


B-13 


1: 


NW BOS-CHI 






3: NW CHI-BOS 


Round Trip 


C-12 


1: 


UACM-MSP 


2: 


UA CHI— MSP 




Round Trip 


D-23 






2: 


UA CHI—MIA 


3: UA MIA— CHI 


Round Trip 


E-23 






2: 


FLMSP-MtA 


3: FLMIA-MSP 


Round Trip 


F-13 


1: 


UA BOS -MSP 






3: UA MSP— BOS 


Round Trip 


G-l 


1: 


NW BOS cm 








One Way 


H-l 


1: 


UACHI-MSP 








One Way 


1-1 


1: 


UA BOS -MSP 








One Way 


J-l 


1: 


CO BOS -MSP 








One Way 


K-2 






2: 


UA MSP— MIA 




One Way 


L-2 






2: 


ua msp— an 




One Way 


M-2 






2: 


UA CHI— MIA 




One Way 


N-3 










3: UA MIA— CHI 


One Way 


0-3 










3: NW CHI— BOS 


One Way 


P-3 










3: UA MSP— BOS 


One Way 



TABLE 32 below lists slice-label-sets that are produced in 
this example, and as with itineraries and itinerary divisions, 
the faring process assigns each a numerical label. Many 
itineraries may be grouped into the same slice-label-set. For 
example, there are three different itinerary divisions that are 
grouped into slice-label-set 1.3. TABLE 30 lists, for each 
slice-label-set, its backward-projection. This is the set of 
multi-slice PU-labels that project onto previous slices. 

TABLE 32 
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TABLE 33 



Multi-Slice 
Slice PU-Labels 



1 


1.1 {A-123} 


1.1 


1.1.1 


{} 


{} 


1 


12 {F-13} 


1.1 


1.1.1 


{} 


{} 


1 


13 {} 


1.1 


1.1.1 


{1-1} 


{} 






1.2 


1.2.1 


{G-l H-l} 








1.3 


1.3.1 


{J-l} 




1 


1.4 {B-13 C-12} 


1.2 


1.2.1 


{} 


{} 


1 


15 {B-13} 


1.2 


1.2.1 


{H-l} 


{} 


1 


1.6 {C-12} 


1.2 


1.2.1 


{G-l} 


{} 


2 


2.1 {A-123} 


2.1 


2,1.1 


{} 


{A-123} 






2.2 


2,2.1 


{} 




2 


22 {} 


2.1 


2.1.1 


{K-2} 


{} 






2.2 


2,22 


{L-2 M-2} 




2 


23 {C-12 D-23} 


2.2 


2.22 


{} 


{C-12} 


2 


2.4 {C-12} 


2.2 


2.2.2 


{M-2} 




2 


25 {D-23} 


2.2 


2.2.2 


{L-2} 


ir 


2 


2.6 {E-23} 


2.3 


2.3.1 


{} 


{> 


3 


3.1 {A-123} 


3.1 


3.1.1 




{A-123} 


3 


32 {D-23 B-13} 


3.2 


3.2.1 


it 


{D-23 B-13} 


3 


33 {D-23} 


3.2 


3.2.1 


{0-3} 


{D;23} 


3 


3.4 {B-13} 


3.2 


3.2.1 


{N-3} 


{B-13} 


3 


35 {} 


3.2 


3.2.1 


{N-3 C-3} 


{} 


3 


3.6 {E23 F13} 


3.3 


3.3.1 


{} 


{E-23 F-13} 


3 


3.7 {E23} 


3.3 


3.3.1 


{P-3} 


{E-23} 



35 Slice Open-Label-Set 



Divi- Single-Slice Backward 40 
Itinerary sion PU- Labels Projection 



45 



50 



55 



60 



Next-Slice 
Projection 



Backward- 
link 

Backward-Link Open- 
Slice- Label-Set Label-Set 



0 


0.1 {} 


{} 




1 


1.1 {A-123} 


{A-123} 


1.1 {A-123} 


1 


12 {F-13} 


{} 


1.2 {F-13} 


1 


13 {} 


{} 


1.3 {} 


1 


1.4 {B-13 C-12} 


{C-12} 


1.4 {B-13 C-12} 


1 


15 {B-13} 


{} 


1.5 {B-13} 


1 


1.6 {C-12} 


{C-12} 


1.6 {C-12} 


2 


2.1 {A-123} 


{A-123} 


2.1 {A-123} 


2 


22 {} 


{} 


2.2 {} 


2 


23 {D-23} 


{D-23} 


2.3 {C-12 D-23} 








2.5 {D-23} 


2 


2.4 {E-23} 


{E-23} 


2.6 {E-23} 


2 


25 {D-23 F-13} 


{D-23 F-13} 


2.5 {D-23} 


2 


2.6 {E-23 F-13} 


{E-23 F-13} 


2.6 {E-23} 


2 


2.7 {F-13} 


{F-13} 


22 {} 


2 


2J8 {D-23 B-13} 


{D-23 B-13} 2.3 {C-12 D-23} 








2.5 {D-23} 


2 


2.9 {E-23 B-13} 


{E-23 B-13} 


16 {E-23} 


2 


2.10 {B-13} 


{B-13} 


2.4 {C-12} 



3 3.1 {} 



{} 



2-2 {} 

3.1 {A-123} 

3.5 {} 

3.3 {D-23} 
3.7 {E-23} 

3.6 {E-23 F-13} 

3.2 {D-23 B-13} 

3.4 {B-13} 



0.1 {} 
0.1 {} 
0.1 {} 
0.1 {} 
0.1 {} 
0.1 {} 
1.1 {A-123} 

1.1 {} 
1.6 {C-12} 
1.3 {} 

1.3 {} 

1.2 {F-13} 
1.2 {F-13} 
1.2 {F-13} 

1.4 {B-13 
C-12} 

1.5 {B-13} 
1.5 {B-13} 

1.4 {B-13 
C-12} 

1.5 {B-13} 

21 {A-123} 

22 {} 

23 {D-23} 

24 {E-23} 
26 {E-23 
F-13} 

28 {D-23 
B-13} 

210 {B-13} 



Shown in the TABLE 33 below are lists for each slice of 
the open-label-sets, as well as their backward-links and their Each open-label-set contains a set of PU-labels that are 
next-slice-projection. This last field is the subset of open still "open", i.e., project onto a subsequent slice. For 
PU-labels that project onto the subsequent slice. It is equal 65 example, the PU-label C-12 does not appear in open-label- 
to the backward-projection of any slice-label-set that is part sets from slice 2 or slice 3. In the pricing-graph, each 
of a backward-link to the open-label-set. open-label-set will be translated into an OR over the 
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backward-links. The backward-links represent paths that 
lead to the open-label -set. Each is a pair (an AND) of a 
slice-label-set with an open-label-set from the previous 
slice. Because TABLE 33 is consistent, the backward- 
projection of any slice-label-set in a link is equal to the 
next-slice-projection of the open-label-set in the link. 
Furthermore, the PU-labels in each open-label-set can be 
constructed by selecting any backward-link, taking the 
union of the PU-labels in the link's open-label-set and 
slice-label^set, and removing any PU-labels that do not 
project forward. 

If there is an empty open-label-set for the last slice, then 
pricing-solutions exist. This open-label-set provides the 
"root" of the pricing-graph, a node that has a child for every 
link. Each of these links will become an AND of the 
slice-label-set and the previous open-label-set. In this way 
open-labcl-sets and slice-label-sets are used to produce the 
pricing-graph. 

FARE-COMBINABIUTY RESTRICTIONS 

The linking procedure described above assumes that there 
are no restrictions on the mixing of priceable-unit-labels 
other than those imposed by itineraries. This is not always 
the case. For example, although the various create-PUs-in- 
markets procedures described above apply fare- 
combinability checks, those checks include only restrictions 
on the fares that may coexist within a priceable-unit. These 
checks include ATPCO categories 101, 102 and 103, but not 
category 104. The category- 10 record-2s that are stored on 
fare-components may also include so called "end-on-end" 
fare-combinability restrictions. These restrictions constrain 
the fares within other priceable-units. One example of such 
an end-on-end fare-combinability constraint is that all fares 
within an entire journey must be published by the same 
airline as the fare with the constraint 

Cross-priceable-unit constraints such as end-on-end fare- 
combinability restrictions complicate the process of finding 
valid fares for itineraries. In general cross-priceable unit 
constrains can be very expensive to evaluate. These con- 
straints can often be efficiently evaluated during the process 
that links the set of valid fares to the sets of flights to form 
a pricing solution. Below, an efficient approach for evalu- 
ating many common end-on-end fare-combinability restric- 
tions is described. 

First, priceable-unit-labels are constructed in such a man- 
ner that all price able -unit- co res within them share the same 
end-on-end combinability restrictions. This is reflected in 
the procedure partition-fare-components-into-sets, 
described previously. During the linking process each 
priceable-unit-label end-on-end fare-combinability restric- 
tion is applied to the fares in other priceable-unit-labels. This 
happens during the initial stage of the linking process, in the 
execution of create-slice-label-sets. Create-slice -label-sets 
iterates over itinerary divisions, and for each division, 
iterates in an inner loop over covering sets of priceable-unit- 
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labels. In this inner loop an end-to-end fare-combinability 
restriction attached to one priceable-unit-label in the set can 
be applied to fares in other priceable-unit-labels within the 
set. If the restriction fails, the set of priceable-unit-labels is 
5 rejected. 

For this procedure it is desirable that every priceable-unit- 
label containing an end-on-end restriction projects onto all 
the slices that the restriction needs to be checked against. 
Some restrictions may only need to be checked against fares 

10 adjacent to the fare-component or priceable-unit containing 
the restriction, while others may need to be applied to every 
other priceable-unit in the entire journey. Hence, if a 
priceable-unit-label projects onto every slice, then its end- 
on-end restrictions can be applied to every other priceable- 

15 unit-label in a potential pricing-solution. 

But, if a priceable-unit-label projects onto only one slice 
(as a one-way priceable-unit-label would) while its restric- 
tion must be applied to priceable-units from several slices, 
then the restriction cannot be applied using the method 

20 described here. In such a case there are several options 
available. One is to reject the set of priceable-unit-labels 
currently under consideration. Another is to accept it, but 
mark it as potentially requiring that any solution containing 
it must be split into several journeys (a "split ticket"). 

When a combinability record-2 is applied in this manner, 
the information available to it at any one time is a set of 
priceable-unit-labels that collectively cover a division of an 
itinerary (one of these priceable-unit-labels contains the 
source record-2). Each of these priceable-unit-labels refer- 
ence one or more priceable-unit-cores,, each of which in turn 
references one or more fares. It is these fares that are 
validated by the combinability record-2. It may be that some 
priceable-unit-cores from within a priceable-unit-label pass, 
while others fail. Several options are available in this 

35 ambiguous case: a new priceable-unit-label can be 
generated, referencing only those priceable-unit-cores that 
pass, or the entire priceable-unit-label can be rejected. The 
second is the more efficient option, though it may cause 
some valid pricing-solutions to be unnecessarily rejected. 

40 CONSTRUCTING SLICE-LABEL-SETS 

Slice-label-sets are constructed during the process of 
producing open-label-sets 282, by the pseudo-code given 
below (TABLE 34). This code is passed the set of itineraries 

45 for a slice. 

For each itinerary and each division within that itinerary, 
all possible sets of PU-labels are enumerated. Each set is 
partitioned into a set of multi-slice PU-labels and a set of 
single-slice PU-labels. A unique slice-label-set is produced 
50 for each collection of multi-slice PU-labels. Within the 
slice-label-set are stored itinerary-label-holders. Each of 
these pairs an itinerary with a set of division-label-holders. 
Each division-label-holder pairs an itinerary division with a 
set of sets of single-slice PU-labels. 



TABLE 34 



create-slice- label-sets (itineraries) 

Subroutine division- PU-labcl-sets(division) 
// 

// Return a list of all the possible sets of PU-labels for this division. 
// 

Let PU-label-sets - { {} } 
For faring-atom in division 

Let new-PU-labcl-scta - { } 

For PU-label in faring-atom.priceable-unit- labels 

For previous-PU-label-sct in previous- PU-label-sets 
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TABLE 34-continued 



new-PU-label-sets +■ pc*tpend(previous-PU- label-set, PU-label) 
PU-label-sets » new-PU- label-sets 
retura(PU- label-sets) 
Let slice-label-sets = { } 
For itinerary in itineraries 

For division in itinerary.divisions 

For PU-labeb in division-PU-label-scts(division) 

Let multi-slice-PU-Iabels = multi-slice- PU-labeb(PU-labeIs) 
Let single-slice-PU-labeb - single-slice- PU-Iabels(PU-bbels) 
Let slicc-labcl-set » find(multi-slice-PU-labcls» slice-label-scts) 
If (slice-label-set = nil) 

slice-label-sct - new-slice-label-set( ) 
slicc-labcl-scLmulti-slice-PU- labels «* multi-slice- PU-labeb 
si ice- la bel-seLdivis ion-single -slice- labels = { } 
Let itinerary-label-holder - fir»d(itinerary, slice-label-set itinerary-label- holders) 
If (itinerary-label-holder = nil) 

itinerary-label-holder = new-itinerary-label-holder( ) 
itinerary-label-holder. itinerary - itinerary 
itmerary-label-holder.divisiDn-Iabel-holdcrs = { } 
slice-label-seUtinerary-label-holders += itinerary-label-holder 
Let division-label-bolder - find(division, itinerary-label-holder.divis ion- label-holders) 
If (division- label-holder - nil) 

division-label-holder = new-division-label-holder( ) 
division-label-holder.division - division 
division-label-holdcr.singlc-slice-label-sets - {} 
itinerary-Iabel-rioldeLdivisiorj-Iabel-holders += division-label-holder 
division-label- holder.single-slice-label-sets += single-slice-PU- labels 
return (slice- label-sets) 



CONSTRUCTING OPEN-LABEL-SETS 

Open-label-sets are constructed slice-by-slice, starting 
from a single, empty open-label-set. For each slice, the first 
step is to produce slice-label-sets using the procedure 
described above and enumerate the current set of open-label- 
sets. For each open-label-set, the projection into the next 



slice is computed. All slice -label-sets with backward- 
projections equal to that next-slice-projection are used to 
create a new set of open multi-slice priceable-unit-labels, 
and from this a new open-label-set is produced. The pseudo 
code below in TABLE 35 describes this. 



TABLE 35 



link- itineraries(itinerary-sets) 

Subroutine projection(PU-labels f slice-number) 
// 

// Return those PU-labeb that project onto this slice. 
II 

Let result - { } 

For PU-label in PU-labels 

[f (find(slice- number, PU-labeLs lice- numbers)) 
result += PU-label 
return(result) 

Subroutine backward-projcction(PU-labels, slice- number) 
// 

// Return those PU-labeb that project onto a previous slice. 
// 

Let result « {} 

For PU-label in PU-labels 

[f (nnd-if-lcss-than(slicc- number, PU-labeUlicc-numbers)) 
result +» PU-label 
return(result) 

Subroutine forward-projection(PU-Iabcls, slice-number) 
// 

// Return those PU-labeb that project onto a subsequent slice. 
// 

Let result » {} 

For PU-label in PU-labels 

If (nnd-if-grcatcr-than(slice-number, PU-labcl.slicc-numbcrs)) 
result += PU-label 
return(result) 
Let initial-open-labcl-set = new^open-label-set( ) 
initial-open-label-setopen-PU-labels = {} 
in itial-opcn-labcl-sct backward-links = {} 
Let open-label-sets list(initial-open-label-set) 

Let open- PU-labeb ope n-label-seLopen- PU-labels 

Let next-slice-projection = projection(open-PU- labels, slice- number) 

For a lice-label-set in slice-label-sets 

Let slice- PU-labels = slice- label -set. multi-si ice- PU-labels 
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TABLE 35-coatinued 



If (nexl-slice-projection - backward-projection(slicc-PU-labeU, slice-number)) 
Let new-open-PU-labels = £brward-projection(uiiion(8lice-PU-labels, open-PU-labels), 

slice-number) 

Let new-open-label-set » find(new-opeD-PU- labels, new-open-Iabcl-sets) 
If (new-open-label-set « nil) 

new-open- label-set - new-open- label -set ( ) 
ncw-open-labcl-set-open-PU-labeU « new-open-PU-labels 
new-open-label-seLbactward-lints = {} 
Let backward-link - new-backward-link( ) 
backward- link-shce-labcl-set = slice-label-sct 
backward- link.open-label-set = open- label-set 
new-open-label-seLbackward- links +— backward- link 
open- label- sets = new-opcn-label-sets 
slice- number += 1 
If (open-label-sets - {}) 
return (nil) 

Else 

// Return the root open-label-set. 
return (nrst(opcn- label -sets)) 



PRICING GRAPH 

Referring now to FIG. 17, a pricing graph 38* (FIG. 3) is 
produced containing logically combinable nodes that can be 
used to efficiently and compactly represent a set of pricing ^ 
solutions 38 (FIG. 1). The pricing graph 38' as used herein 
is a so-called directed acyclic graph although other types of 
representations could be used. For example, a grammar 
could be used. 

The pricing graph 38 1 is constructed 300 from data 30 
structures 300a (summarized below in TABLE 36 and 
mentioned in conjunction with FIGS. 4A-4B) provided 
during the preceding processes. The data structures convert 
300ft to one or more nodes in the pricing graph. The 



open-label-set data structure becomes an OR node and its 
children are the converted versions of its backward links. 
Each backward link in the open label set is converted to an 
AND node. If a pricing object is shared, for example, a 
priceable unit core is shared between several priceable unit 
labels, then its counterpart nodes in the pricing graph will be 
shared so that the size of the pricing graph is not unneces- 
sarily enlarged. The converted nodes are placed 300c in the 
pricing graph nodes. Terminal objects such as fares and 
itineraries undergo essentially no conversion. They are 
placed 300d into special terminal nodes with no children and 
are obtained from the various data structures that have the 
pricing objects. 



TABLE 36 



Data-Structure Type 


Type 


Child Fields 


open-labcl-sct 


OR 


backward-links (each a backward-link). 


backward-link 


AND 


open-label-set (an open-label-set), 
slice-label-set (a slice-label-set). 


slice-label-set 


AND 


multi-slice- PU-labcls (each a priccable-unit-label). 




(OR) 


itinera ry-label-holders (each an itinerary-label- 
holder). 

The itinerary-label-holders are put into an OR and the 
OR is placed under the AND, which also includes all 
mul ti-slice-PU-labels. 


itinerary-labcl- 


AND 


itinerary (an itinerary). 


holder 


(OR) 


division- label -holders (each a division-label-holder). 
The division-label-holders are put into an OR and the OR 
is placed in an AND with the itinerary. 


division-label-holder OR 


single-slice- PU- label -sets 




(AND) 


(each a set of sets of PU-labels). 

The inner sets are put into ANDs, and these are all 

embedded under an OR. 


priceable-unit-1 abel 


OR 


priceable-unit-cores (each a priceable-unit-oore). 


priccable-unit-core 


AND 


fares (each a fare). 

surcharges (each a surcharge, penalty, discount, etc.) 


fares 


Term 




itinerary 


Term 




surcharge 


Term 
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In cases where a node has only one child, there is do need 
to produce the node. Rather, a direct link can be passed to its 
child. This does not alter the interpretation of the pricing- 
graph, but can result in a smaller graph. 

The pseudo-code below TABLE 37 summarizes construe- 5 
tion of the pricing graph, given the "root" open-label-set that 
is the output of the linking process. 
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compact way of representing these pricing solutions. The 
compact representation of the range of set of pricing solu- 
tions is generated where choices are represented explicidy 
and redundancy is removed wherever possible. 

As mentioned above, the pricing graph 38' produced by 
the search procedure 54 includes three types of nodes. The 
first type of node is a node that represents choices called 



TABLE 37 



create-pricing-graph(root-object) 
Let nodes » {} 

Subroutine convert-object(object) 

// Convert the object and cache the result, so that nodes with multiple parents arc shared 
Let node = find (object, nodes) 
If (node = nil) 

node - convert(object) 
nodes += node 
return (node) 
Subroutine convert-objects (objects) 

// Convert the set of objects and return a set of nodes. 

Let result = {} 

For object in objects 

result += convert-objcct(object) 
retum(result) 
Subroutine create-node(chiIdren, type) 

// Create a node of type type with children children, if there is more than one child. 
// Otherwise the node is unnecessary, and the only child is returned. 
If (length(children) - 1) 
return(first(child) 

Else 

Let node - new-node( ) 
node.type =• type 
node, children = children 
node, terminal -object - nil 
return(node) 

The pricing graph 38' resulting from the search procedure 54 

Subroutine convert(object) 

Let object-type = type(objcct) 
If (type = open- label-set) 

return (create-node(convert-objects (object backward-links), OR)) 
Else If (type » backward-link) 

retum(create-node(list(co nvert-obj ect(object. slice-label-set), convert-object(objecLopen-label-set)), AND) 
Else If (type = slice-label-set) 

Let children - convert-objects(objecLmulti-slice-PU-labels) 

children += create-node(convert-objects(object itinerary-label- holders), OR) 

return(create-node(children > AND)) 
Else If (type - itinerary- label -holder) 

Let children « convert-objects(object,division-label-holders) 

children +*» create-node(convert-objects(object. itinerary), OR) 

return (create- node( children, AND)) 
Else If (type = division- label- holder) 

Let children = {} 

For single-slice-PU- label-set in object single-slice- PU- label-sets 

children += create- node(convert-objects(single-slice-PU- label-set), AND) 

return (create- node(childrea, OR)) 
Else If (type - priceable-unit- label) 

rctum(create- node(co nvert-objects (object priceable-unit-corcs), OR) 
Else If (type = priceable-unit-core) 

return (create-node(append(convert-objects(object fares), convert-objectsfobjectsurcharges)), AND) 
Else // object is a terminal. 

Let node = new-node( ) 

node.type - terminal 

Qodexhildren » {} 

node. terminal-object o object 

return (node) 
return(convert-object(root-object)) 



provides a compact way for representing a very large 
number of set of pricing solutions. By the above process, it 
is often possible to obtain a very large number of pricing 
solution components. Although the number of pricing solu- 
tions can be returned in the form of a simple list, this is not 
desirable. A very large number of pricing solutions can be 
difficult to manipulate, enumerate and interrogate and to 
transfer/transmit across a network since the amount of data 
involved is very large. The pricing graph 38' provides a more 



"LOGICAL OR" nodes. The second type of node is a node 
that represents collections referred to as "LOGICAL AND" 
nodes. A third type of node represented in the pricing graph 
is a terminal node that represents pricing objects. 

A data structure representation (TABLE 38) of the nodes 
is set out below. Each node contains a "type", which 
specifies whether the node is an AND node, or OR node or 
a terminal node. The data structure also contains either list 
of children (if the node is an AND node or an OR node) or 
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a terminal object (if the node is a terminal). The node 
contains fields that store values used by algorithms that 
manipulate the pricing graph 38'. 

TABLE 38 



Node fields 


Use 


type 


Either AND, OR or TERMINAL 


children 


A list of child-nodes, if node is AND or OR. 


terminal-object 


A terminal-object such as a fare or itinerary, 




if the node is TERMINAL. 


active7 


True or false, depending on whether the node is 




active. 


inner-value 


The node's minimum possible inner- value. 


outer-value 


The node's minimum possible outer-value. 


total- value 


The node's minimum possible total-value. 


best-child 


For OR-nodes, the child with the least-positive 




inner-value. 



As mentioned above, the pricing graph 38* is a compact 
representation of a set of set of pricing solutions. The typical 
number of set of pricing solutions represented by pricing 
graph ranges from tens of millions into hundreds of billions 
with the number of nodes in the graph ranging from thou- 
sands to tens of thousands. The pricing graph can be easily 
stored and/or transmitted over a network or other connection 
to a client and represents complete representation of all or 
substantially all of possible pricing solutions. Therefore, the 
pricing graph 38' can be used by a smart client without 
further intervention from the server 12. 
MANIPULATING THE PRICING-GRAPH 

Referring now to FIG. 18, a high level illustration of a 
process 301 that operates on the pricing graph 38' typically 
as a client process 36 on the client computer system is 
shown. The process 301 includes a user query 302 that 
passes parameters into a process 304 and a value function 
306 to extract from the pricing graph 38' certain pricing 
solutions 308 that satisfy parameters specified by the user 
query 302. The extracted pricing solutions are returned as a 
list 308 or other representation. Generally the pricing solu- 
tions are displayed on the display 40. Display software 309 
handles production of GUI's 41 to present the information. 

The pricing solution list 308 will contain pricing solutions 
extracted from the pricing graph 38* in accordance with user 
specified parameters from the user query 302 using one of 
the processes 304 and one of the value functions 306. 

Referring now to FIG. 19, illustrative processes are 
shown. In particular, in response to the user query 310, one 
of the processes is executed. The processes 312 can com- 
prise a find best "value" and pricing solutions associated 
with the value (e.g., price) process 312a; find best "value" 
and pricing solutions associated with the value for "node" 
(e.g., find best price for a particular itinerary) process 3126; 
an enumeration for "N" pricing solutions 312c; or an enu- 
meration process that lists the pricing solutions according to 
some "value ."Additional enumeration processes can be pro- 
vided to produce query results corresponding to different 
ways of looking at pricing solutions extracted from the 
pricing graph 38*. A node invalidating process 314 that 
invalidates selected nodes from contributing to a pricing 
solution is also included. 

Examples of each of these processes are set forth below. 

Efficient algorithms 312 are used for manipulating this 
representation to extract information of interest and to 
enumerate set of pricing solutions from the structure. For 
example, it is possible to quickly extract the cheapest 
solution; to find the cheapest solution involving selected 
fares and itineraries; to verify whether any pricing solution 
remains if specific fares or itineraries are excluded; to 



enumerate solutions under various orderings and so forth. 
Furthermore, the representation is compact enough so that it 
can be efficiently stored and transmitted such as from the 
server to the client One benefit, therefore, is that after a 

5 single fare search 54 in the server process 16, the server 
process 16 transfers the pricing graph 38 to the client process 
36. The client process 36 can examine and manipulate the 
large space of pricing solutions represented in the pricing 
graph 38' without further interaction with the server process 

to 18. 

For the set of pricing solutions represented by the pricing 
graph 38* to be useful, processes are provided to extract 
pricing solutions from the graph and manipulate the set of 
pricing solutions, as depicted in FIG. 19. In general, each of 

15 the enumeration processes to be described operate on the 
pricing graph to extract pricing solutions from the pricing 
graph according to particular criteria that can be set, for 
example, by a client system 30c (FIG. 2) in response to a 
user query 48 (FIG. 4). Examples of user queries as well as 

20 a display representation for information extracted from the 
pricing graph will be described below. 

An example of an enumeration function enumerates pric- 
ing solutions in a specific order. For example, an enumera- 
tion function can enumerate the 100 cheapest pricing solu- 

25 tions represented by the pricing graph 38'. A second 
enumeration function can find extreme points of the set of 
pricing solutions. This can be used, for example, to find the 
most convenient pricing solution. In addition, a value func- 
tion can specify a minimum value of some value over the set 

30 of pricing solutions that involve a particular node. One value 
function finds for each itinerary the cheapest pricing solution 
that involves that itinerary or the shortest total duration of 
any pricing solution that involves that itinerary. 
In addition, each of the above operations can be per- 

35 formed on a subset of the graph. For example, it may be 
desirable to enumerate the 100 cheapest solutions that 
involve a given itinerary or finding the most convenient 
solution that involves only refundable fares or includes only 
certain airlines or excludes certain airlines. 

40 VALUE FUNCTIONS 

Referring now to FIG. 19, many processes or operations 
on the pricing graph 38' use a value-function, a function that 
operates on the terminal nodes of the pricing graph 38' and 
returns a numerical value that can be used to rank pricing- 

45 solutions. Examples of value-functions include price com- 
puted by summing the prices of fares (and penalties and 
surcharges) in a pricing-solution, duration, or convenience 
(that might be a mix of total travel-time with penalties for 
stops and airline-changes, for example), or mixes of each. 

50 Many of the processes used to manipulate the pricing 
graph 38' depend on a value-function being decomposable 
into the sum of a second function that is applied to individual 
terminal nodes in the pricing-graph. The "price value func- 
tion" meets this requirement, because the total price of a 

55 pricing-solution is equal to the sum of the prices of fares. 
Many expressions of convenience also meet this 
requirement, including those that can be computed as the 
sum of a function applied to individual itineraries. However, 
there are some value-functions that cannot be placed into 

60 this form. An example is a "convenience" function that 
checks whether travel in different slices is on the same 
airline. Such a function depends on all itineraries at once. 

In general, in the discussion below, the term node-value- 
function is used to refer to a function that is applied to 

65 individual nodes in the pricing-graph, and summed to pro- 
duce the value of an entire itinerary. The term value-function 
is used for the more general case of a function that may or 



12/30/2002, EAST Version: 1.03.0002 



US 6,295,521 Bl 



51 



may not be decomposable into the sum of a nod e- value - 
function applied to each terminal in the pricing-graph. 
FINDING THE BEST PRICING SOLUTION 

The first process 312a is an example of one that finds 
extreme points of the set of pricing-solutions, such as the 5 
cheapest pricing-solution. 

Assuming that it is desired to find a pricing-solution that 
minimizes some value-function that can be decomposed into 
a node -value-function F, the best pricing solution could be 
found by enumerating all pricing-solutions and applying F to 10 
each of them. This is impractical because of the large 
number of set of pricing solutions. 

The Best Price algorithm 312a' efficiently finds the cheap- 
est (best) price by starting at the "bottom" of the pricing- 
graph 38' and constructing the best solution for each node by 15 
looking at the best solution of its children. In this way it 
works in one pass from the bottom of the graph to the top. 
At the end of the process the root node contains the best 
pricing solution for the entire pricing graph 38. 

The algorithm proceeds as follows: first, the nodes in the 20 
graph are ordered by depth and placed in a list, so that 
iterating over the list ensures that a child node is always 
encountered before its parents). Then, iterating across the 
list, the best value of F is computed for each node, using the 
already-computed values of F for its children. At this point 25 
every node in the graph is marked with its inner-value. The 
inner-value of a node is the best possible value of the 
function F on the set of (partial) pricing-solutions repre- 
sented by the node. As inner-values are computed, for every 
OR node the child with the lowest inner-value is computed 30 
and stored. Finally, the best pricing solution can be con- 
structed by starting at the root of the graph and collecting 
children. Whenever an OR node is encountered, the best 
child is chosen (the child with the lowest inner-value). 

If a node is a terminal fare or itinerary, then its inner-value 35 
is the value of F applied to the node. If the node is an ANT), 
representing a combination, then the minimum value of F 
over the partial solutions it represents is the sum of the 
minimum values of F over the partial solutions represented 
by each of its children. If a node is an OR, representing a 40 
choice, then the minimum value of F over the partial 
solutions it represents is found by making the optimal choice 
of children, that is, the child with the minimum inner-value. 
So the inner-value of an OR is the minimum of the inner- 
values of its children. 

The pseudo-code in TABLE 38 summarizes the compu- 
tation of inner-values. The function sort-nodes takes a root 
node and returns a list of all nodes under it, sorted by depth 
with the root node at the end. The procedure compute-inner- 
values takes in a sorted list of nodes as would be produced so 
by sort-nodes, and a node-value-function. The procedure 
find-optimal-solution takes in a root-node and a node- value - 
function, calls sort-nodes and compute-inner-values to cal- 
culate inner-values for all nodes in the pricing-graph, and 
constructs a pricing-solution. 55 

TABLE 38 

sort-nodes(node) 
Let nodes = {} 

For child in node, children 60 
nodes - append(nodes, son- nodes (child)) 

nodes +- node 

return (nodes) 

compute- inner- values(sorted- nodes, 
node- value-function) 
For node in sorted- nodes 65 

If (node. type - terminal) 
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TABLE 38-continued 



nodcinner-value » apply(node-value- function, 
node .terminal-object) 
Else If (nodctype - OR) 

node inner-value - infinity 
For child in nodcchildren 

[f (child.inner-varue < nodeinner-value) 
nodeonner-valuc = child, inner- value 
node best-child = child 
Else If (node, type - AND) 
node .inner- value = 0 
For child in node. children 

node.inner- value +- childLinner-value 
find-op Lima I -solution (root- node, node-value-function) 
Subroutine get- node-solution (node) 
If (node.type - terminal) 

retarnQist(node.tcrrriinal-object)) 
Else If (node, type = OR) 

return(get- node-eohitio n(node. best-child) 
Else If (nodctype = AND) 
Let solution = {} 
For child in nodcchildren 

solution - append (solution, get-nodc-sorution(child)) 
return(solurion) 

con^}ute-inner-values(sort-nodes(root-node) > node-value-function) 
return (ge t- node- so lutio n (root- node)) 



FINDING MINIMUM VALUE 

Another procedure 3126 finds, for each node, the best 
(i.e., minimum) value of some value-function over all the set 
of pricing solutions involving that node. Another procedure 
312b 1 finds for the best value, e.g., price and/or solutions 
involving "none" of the nodes. Price function 312b finds for 
each itinerary, the cheapest price of any pricing solution that 
contains that itinerary. These values can be computed 
efficiently, if the value-function can be decomposed into a 
node-value-function. 

The best price value function 306a computes inner- 
values, as above, and computes for every node, an outer- 
value, equal to the minimum value contributed by all parts 
of the graph except that represented by the node. For each 
node, the minimum value of the value-function over all 
solutions that involve the node, (i.e., the total-value) is 
computed as the sum of that node's inner- value and outer- 
value. 

The outer-value and total-value of a node are computed in 
a manner very similar to the computation of the inner-value. 
In particular, the outer-value for each node is calculated 
starting from the root of the graph, that has an outer-value of 
0. Each node propagates outer- values down to its children. 
An OR-node passes its outer-value unchanged. An AND- 
node adds to its outer-value the inner-values of all children 
except that being propagated to. At every node, after the 
outer-value has been computed, the total-value is computed 
as the sum of the inner-value and outer- value. 

When outer-values are propagated from a node to its 
children, a minimum computation is performed. This is 
because each child may have more than one parent, and its 
outer-value must be the minimum outer-value contributed 
by any parent. See TABLE 39 below. 
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TABLE 39 

compute-ouur-and-lotaJ-values(root-node, node- value-function) 

// Sort nodes and computer inner- values. 

Let sorted- nodes - sort-nodes(root-node) 

ooirnpute-inner-values(Borted-nodes, node-value- function) 

Let reversed- nodes o reverse (sorted- nodes) 
// Initialize all nodes to have outer- values of infinity. 
For node in revcrsed-nodcs 

node .outer- value => infinity 
// The root-node has an outer-value of 0. 
njst(reversed-nodes).outcr-varuc = 0 
For node in reversed-nodes 

// Compute the total-value for the node. 

node .total- value » nodcinncr- value + node.outer- value 

If (node.type » OR) 

// For OR nodes, the outer-value is propagated down to its children unchanged. 
For child in nodexhildren 

child, outer-value « minimum (child .outer-value, node. outer- value) 
Else If (node.type - AND) 

// For AND nodes, the outer- value is propagated down by adding the inner- values of 
// all but the child being propagated to. This is equal to the node's inner-value minus 
// the child's inner-value, which is equal to the node's total- value minus the child's 
// inner-value. 
For child in node.children 

child. outer- value - rninimum (child .outer- value, node.total -value - child. inner- value) 



INVALIDATING NODES 

It may be desirable to "invalidate'* 314 certain nodes from 
the pricing-graph 38'. For example, itineraries containing or 
not containing specified airlines could be marked as not 
participating in the above algorithms, enabling the algo- 
rithms to find the best solutions involving or not involving 
these itineraries. The above algorithms can be easily adapted 
to accommodate checking whether the node is valid. In 



particular, the computation of inner-values, the first step in 
all the above algorithms, is modified to mark for every node 
whether the node represents any valid partial pricing- 
solutions given a specific query parameter. This information 
can be used in the rest of the algorithms. Every terminal 
node contains a field "valid?" that is either true or false. The 
compute -inner-values procedure uses these values to set the 
"valid?" field for non-terminals. See TABLE 40 below: 

TABLE 40 



25 



30 



// Initialize all nodes to have outer-values of infinity. 
For node in reversed-nodes 

node .outer-value « infinity 
// The root-node has an outer-value of 0. 
firs tfreversed-nodeB) .outer-value - 0 
For node in reversed-nodes 
If (node.valid? =» true) 

// Compute the total-value for the node, 
nodc.total-value » node.inner-varuc + node.outer-value 
If (node.type «* OR) 

// For OR nodes, the outer-value is propagated down to its children unchanged. 
For child in node.children 

childouter-value = minimum(child.outer-value, node^uter-value) 
Else If (node.type = AND) 

// For AND nodes, the outer-value is propagated down by adding the inner-values of 
// all but the child being propagated to. This is equal to the node's inner-value minus 
// the child's inner-value, which is equal to the node's total-value minus the child's 
// inner-value. 
For child in node.children 

child, outer- value = minimum(child.outer-value, 

node, total- value - child. inner- value) 

sort-nodes (node) 

If (not(find(node,nodes))) 

For child in node, children 

sort- nodes- inner(child) 

nodes +» node 

sort-nodes-inner(node): 

return (nodes) 

co mpute- inner-values (sorted- nodes.node- value- functio n) 
For node in sorted-nodes 

If (node.type » terminal) 

node. inner-value •= apply (Dode- value-function, note. terminal-object) 
Else tf (node.type - OR) 

node. inner-value » infinity 

node.valid? - false 

For child in node.children 

tf (child-valid? = true and child, inner value < node, inner- value) 
node. inner-value = child. inner-value 
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TABLE 40-continued 



node.best-cbiJd - child 
node.valid? - true 
Else If (nodc.type - AND) 
node, inner-value ° 0 
node.valid? = true 
For child in nodcchfldren 
If (child.valid? = true) 

node.inner-value += child, inner- value 

Else 

node.valid? •» false 
find-optimal-solutioQ( root- node, node-value-function) 
Subroutine get-node-sotution(node) 
If (node.typc = terminal) 

retu rn(l ist(node.terminal-object)) 
Else If (node.type - OR) 

return(get- nodc-$olution(nodcbes t-chQd) 
Else If (node.typc « AND) 
Let solution - {} 
For child in nodexhildren 

solution * &ppend(soluiion, get- node- solution (child)) 
return(solution) 

computc-inncr-values(sort-nodes(root-node), node- value- function) 
If (root-node. valid? « true) 

return (get- node-sohition(root-node)) 

Else 

return (nil) 

compute-outer-aod- total- values(root- node, node- value-function) 
// Sort nodes and computer inner-values. 
Let sorted- nodes = sort-nodes(root-node) 
compute-inner- values(sorted- nodes, node- value-function) 
Let reversed-nodes - reverse(sorted-nodes) 

// Initialize all nodes to have outer-values of infinity. 
For node in reversed-nodes 

node.outer-value - infinity 
// The root-node has an outer-value of 0. 
first(reversed-nodes). outer- value = 0 
For node in reversed-nodes 
If (node.valid? = true) 

// Compute the total-value for the node. 

node, total -value - node.inner- value + node.outer-value 

If (node, type = OR) 

// For OR nodes, the outer-value is propagated down to its children unchanged. 
For child in node.children 

child-outer-value = rniru*mum(child.outer-value, nodcoutcr-valuc) 
Else tf (node .type = AND) 

// For AND nodes, the outer-value is propagated down by adding the inner-values of 
// all but the child being propagated to. This is equal to the node's inner-value minus 
// the child's inner-vahie, which is equal to the node's total-value minus the child's 
// inner-value. 
For child in node.children 

child. outer- value - muiimuin(child.outer-vaIue, 

node.total-value - child.inner-value) 



ENUMERATING PRICING SOLUTIONS 

It is often desirable to arbitrarily enumerate many pricing 
solutions: the best, the second-best, the third-best, etc. 

The enumeration algorithm 312c maintains a queue of 
partial-solutions, ordered by the lowest possible total value 
(e.g., price 312c) of the value-function over all complete 
solutions that contain the partial-solution. At the start of the 
search, a single partial solution is constructed from the root 
node of the pricing-graph 38'. At each step the best partial- 
solution is dequeued, and expanded. Each partial-solution 
has a set of non -terminal nodes and a set of terminal objects. 
A partial-solution is expanded by selecting a non-terminal 
node and substituting the node's children (all of its children 
in the case of an AND, one of its children in the case of an 
OR). If a dequeued partial-solution contains only terminal 
objects, it is complete, and is returned. This process contin- 



ues until the desired number of pricing-solutions that can be 
specified by a user has been produced. 

The algorithm can accommodate value-functions that 
cannot be decomposed into the sum of a node-value- 
function. It does this by applying a second penalty-value- 
function to partial pricing-solutions as it constructs them. 
This function returns a non-negative number when given a 
new terminal object and existing set of terminal objects. The 
number is added to the values produced by the normal 
node-value-function. If the number is positive, it acts as a 
penalty. An example of how this could be used is for the case 
where a penalty is applied if travel in two slices is on 
different airlines. The penalty-value- function would return a 
(positive) penalty if the terminal was an itinerary, and the set 
of existing terminals contained an itinerary with travel on 
different airlines. Otherwise it would return 0. See TABLE 
41 below. 
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TABLE 41 



compuic-inncr-valucs(sortcd-Qodcs, node- value-function) 
Foi node in sorted- nodes 

If (nodctype - terminal) 

node. inner-value - a pp I y(oode-va rue- function, node. terminal -object) 
Else If (nodctype » OR) 

node.inner-valuc - infinity 

node.valid? = false 

For child in node. children 

If (child.valid? - true and child. inner- value < node.inner-value) 
node.inner-value = child, inner- value 
node.best-cnild => child 
node.valid? - true 
Else If (nodctype = AND) 
node.inner-value » 0 
node.valid? - true 
For child in node. children 
If (child.valid? « true) 

node.inner-value +- child, inner- value 

Else 

node.valid? = false 
fhd-optimal-solution( root- node, node-value-function) 
Subroutine get- node-solution (node) 
If (nodctype = terminal) 

re nirn(list(node.terminal -object)) 
Else If (nodctype - OR) 

return(get-node-solution(Dode.best-daughtei) 
Else If (nodctype - AND) 
Let solution - {} 
For child in node.children 

solution = append(solution, get- node- solution (child)) 
return(solution) 

computc-inner-values(sort-nodes(root-node), node- value- function) 
If (root-Dode.valid? = true) 

return(get-node-sohition (root-node)) 

Else 

return(nil) 

compute-outer-and- total- values(root-node, node- value-function) 
// Sort nodes and computer inner- values. 
Let sorted- nodes <=> sort- nodes( root- node) 
compute-ianer-values(sorted- nodes, node- value-function) 
Let reversed- nodes = revcrsc(sorted- nodes) 
// Initialize all nodes to have outer-values of infinity. 
For node in reversed-nodes 

node .outer-value = infinity 
// The root-node has an outer-value of 0. 
firstfreversed-nodes). outer-value - 0 
For node in reversed-nodes 
If (nodcvalid? = true) 

// Compute the total-value for the node. 

nodctotal-value = node.inner-value + nodcouter-value 

If (nodctype = OR) 

// For OR nodes, the outer- value is propagated down to its children unchanged. 
For child in node.children 

childouter- value = minimum(child. outer-value, node. outer- value) 
Bse If (nodctype - AND) 

// For AND nodes, the outer- value is propagated down by adding the inner- values of 
// all but the child being propagated to. This is equal to the node's inner- value minus 
// the child's inner- value, which is equal to the node's total-value minus the child's 
// inner- value. 
For child in node.children 

child, outer- value = m inimurn(child .outer- value, 

node.total-value - child. inner- value) 



Referring now to FIG. 20, a window 350 that is part of a 
graphical user interface of the client process 36 (FIG. 3) is 
shown. The graphical user interface permits the user to 
access inter alia the enumeration processes 304, value func- 
tions 306 and invalidate routine 307. The graphical user 
interface has user selectable controls 352 such as "origin" 
and "destination". There are also controls for selecting time 
and date. In addition, there are controls 352 that specify 
"slices" of a journey. The user enters values corresponding 
to origin, destination, dates and time by selecting an appro- 
priate one of the controls. The origin and destination con- 
trols 352 invoke a query window (FIG. 21) where the user 
can enter a value. After the origin destination and preferably 



date and time information are entered, a user control "GO" 
becomes activated. Pressing the "GO" button will, for an 
initial query, send the query to the server process 18. The 
server process handles the query and initiates the server 
process 18. The server process 18 returns to the client 

60 process 36 a set of pricing solutions in a compact represen- 
tation such as the pricing graph 38'. 

Referring now to FIG. 21, a query entry window 360 is 
shown. The query entry window 360 is produced by acti- 
vating either the ORIGIN or DESTINATION controls352 in 

65 the window 350. The query window 360 includes a user 
entry area 361 for entering a destination code or origin code 
(as appropriate) such as a three letter airport code or a 
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location such as a city, region or country (e.g., Turkey). 
Region 364 depicts a listing of airports in a region about the 
location entered in area 361, whereas area 364 lists origins 
and destinations of a flight slice (none shown) that has been 
selected for the query. In addition, in the entry area 361 the 
user can enter more than one airport or region. The query can 
be constructed, therefore, with two or more origins and 
destinations appearing in each slice of a journey and the 
pricing solution would be determined for the various com- 
binations. 

Referring now to FIG. 22, a window 370 is illustrated. 
Window 370 appears after a user query input to the server 
process 18 producing the pricing graph 381 that is sent to the 
client process 36 (FIG. 3). Window 370 is an example of a 
single slice journey. Since window 370 depicts a one-way 
(i.e., single slice journey), only controls 352 corresponding 
to the first slice are shown as activated with information 
about the slice. Window 370 includes the same controls or 
buttons 352, as described above with respect to window 350. 
The window 370 also includes a series of user preference 
controls 354, here "Nonstop", "Direct", "Online (on the 
same airline)" and "Select" shown as not activated and "1st 
class", "2nd class" and "Refundable" shown activated. The 
Nonstop, Direct and Online controls when selected by a user 
will eliminate all components from the pricing solution that 
do not correspond to nonstop, direct or online flights. A 
select control operates in conjunction with the user marking 
one or more potential pricing solutions such that the num- 
bers which appear shaded out are activated. When one or 
more of the pricing solutions are activated and the select 
button is pressed, the client process extracts pricing solu- 
tions from the pricing graph. The "1st class", "2nd class'* 
and "Refundable" controls when activated eliminate fares 
that do not correspond to these classes of travel. 

Hie window 370 also includes a listing 372 of airports 
involved in the results provided from the pricing graph 381, 
as well as, a listing 374 of airlines. 

The window 370 has a graphical region that provides a 
visual representation of pricing solutions extracted from the 
pricing graph 38*. One preferred representation of the pric- 
ing solution is a horizontal bar graph 376. The itineraries are 
ordered by increasing total fare with each entry 376a of the 
bar graph corresponding to a set of flight segments on 
airlines that provide travel from the origin (e.g., *ESB') to 
the destination (e.g., SAN, San Diego International Airport) 
on airlines coded in accordance with the legends for the 
airline in listing 374 with stopovers denoted by airports. The 
bar graph representation displays a metric of the pricing 
solution in a graph format. Thus, as shown for the first entry 
376a, there are two legs 377a, 3776 on airline "TK" with a 
stopover 377c at airport "JFK" and two legs 377a* and 377e 
on airline "HP" arriving in San Diego (SAN). As shown in 
FIG. 22, twenty-one possible solutions are represented in the 
horizontal bar graph ordered by increasing total fare. This 
typically represents a small fraction of the total number of 
pricing solutions that may be represented by the pricing 
graph 38'. Other ones, if they exist, can be revealed by 
manipulation of a scroll bar 355. 

Referring now to FIG. 23, a window 380 illustrates a 
sample pricing solution including an itinerary 382 and fares 
384. In this embodiment, such a window is produced by 
double-clicking on an itinerary such as 376a. Such a pricing 
solution is extracted from the pricing-graph 38' by invali- 
dating 314 all other itineraries in the same slice and then 
using procedure 304a to find the single cheapest remaining 
pricing-solution. The window 380 illustrates the sample 
outbound itinerary 382 with fares 384. The itinerary 382 can 
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be selected, for example, by double clicking on the itinerary 
or by using the right button of a computer mouse and so 
forth. For example, what is displayed in this interface are the 
itineraries (which are TERMINAL NODES in the pricing 
5 graph 38') along with their associated "lowest prices" that 
are computed by running algorithm 304r> (with value func- 
tion such that it computes for every node in the graph the 
lowest total price for any pricing solution involving the 
node. 

10 Referring now to FIG. 24, a second example of a window 
390 containing pricing solutions is shown. Window 390 
illustrates a round trip journey between Boston (BOS) and 
San Diego (SAN). The window 390 includes a section 
including user controls 352 that permit user entry and 

IS modification of the results in the window as described above 
in conjunction with FIG. 22. Here, however, controls are 
shown activated for both slice 1 and slice 2 of the journey. 

The window also includes the airport 372 and airline lists 
374 and a graphical representation 400 of information (e.g., 

20 itineraries) with a subsection 402 corresponding to outbound 
or first slice information (e.g., itineraries) and section 404 
corresponding to inbound or second slice information. Each 
graphical section 402, 404 is a horizontal bar graph and 
includes scroll bar controls 403 and 405, respectively. In 

25 addition, the window also includes user preference controls 
354 shown activated for the first and the second slices of the 
journey. 

In a similar manner as discussed in conjunction with FIG. 
23, double clicking or otherwise selecting an illustrative 

30 ITINERARY, for example, the first ITINERARY 392a will 
produce an itinerary window 410 (FIG. 25) that depicts 
information corresponding to the selected outbound itiner- 
ary 412 as well as information for possible return itineraries 
414 selected in accordance with the current outbound itin- 

35 erary. The window 410 also includes fare information 416. 
Referring now to FIG. 26, a window 390' is shown. This 
window depicts a subset of the set of pricing solutions 
represented by the pricing graph as displayed in window 390 
(FIG. 24). The subset is selected by activating the "Select" 

40 button and highlighting a pricing solution (e.g., 392#, FIG. 
24). The window 390' depicts possible return itineraries that 
can be matched with the selected outbound itinerary 392g 
and the corresponding total fares for the itinerary. This 
operation modifies the pricing solutions and is performed 

45 within the client process 36. The client process uses the node 
invalidating function described in conjunction with FIG. 19. 

Another process that can use the node invalidated func- 
tion 314 described in conjunction with FIG. 19 would permit 
the user to point and click at certain airports and/or airlines 

50 represented as icons in fields (not numbered). In one mode, 
by selecting airline and/or airport pricing solutions that do 
not include the selected airline or airports are not extracted 
from the pricing graph 38'. In an alternate mode, selecting an 
airline or airport does not extract solutions containing the 

55 selected airline and/or airport from the pricing graph. 

The pricing graph can be viewed in other ways through 
the activation of the pull down menus shown in any of FIGS. 
22, 24 and 26. For example, as shown in FIG. 22, there are 
four pull down menus "refresh", "outbound display", "return 

60 display" and "search properties." The refresh display will 
permit storing queries and permit a user to refresh the 
display. The outbound display menu will permit the user to 
resort the data according to any one of a number of char- 
acteristics. Example characteristics include, but are not 

65 necessarily limited to, cost, duration, departure time, arrival 
time, number of legs, number of segments and so forth. The 
outbound display can also be adjusted to allow a user to 
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change the horizontal axis to a time or duration axis as well 
as change the itinerary size to have it displayed small or 
large. A similar arrangement is provided for the return 
display. The search properties allow a user to conduct a 
faring search by computing fares or not computing fares, 5 
that is, by providing complete pricing solutions or merely 
just activating the schedule portion of the server process 18. 
The search properties also permit the user to search by legs 
or segments, specify a search time, a number of itineraries 
and number of extra itineraries to discard. 10 

Each of the display options referred to above make use of 
one or more of the value functions and processes described 
in conjunction with FIG. 19 and permitting the client process 
to extract or manipulate the pricing graph 38'. Accordingly, 
the pull down menus as well as the other controls on the 15 
graphical user interface are the user interface to the "value" 
functions and enumeration processes described above. 

Referring now to FIG. 27, a window 500 is shown. The 
window 500 includes an ensemble of travel options depicted 
as a histogram 502. The histogram 502 is a plot of an metric 20 
or option such as time as the x axis versus the number of 
itineraries on the y axis. Portions of the histogram repre- 
sentation can be selected and the processes above will 
invalidate all travel node that are not selected. These will 
provide corresponding changes in a bar graph representation 25 
504 disposed below the histogram 502. This will also affect 
a list airports 506 by possible changing a visual appearance 
of icons in the list 506. 

OTHER EMBODIMENTS 30 

It is to be understood that while the invention has been 
described in conjunction with the detailed description 
thereof, the foregoing description is intended to illustrate 
and not limit the scope of the invention, which is defined by 
the scope of the appended claims. Other aspects, advantages, 35 
and modifications are within the scope of the following 
claims. 

What is claimed is: 

1. A travel planning system comprising: 

a server process that determines travel planning informa- 40 

tion in response to a travel request query; 
a client process, to send the travel request query and that 
receives the travel planning information, said client 
process comprising: 45 
a manipulation process that operates on the travel 
planning information, to extract, in response to a 
subsequent user command, travel options from the 
travel planning information sent from the server 
process. 50 

2. The system of claim 1 wherein the server process and 
the client process execute on the same computer. 

3. The system of claim 1 wherein said manipulation 
process of said client process operates on the travel planning 
information in accordance with at least one user command, JS 
and further comprises 

a process that produces a set of travel planning informa- 
tion by fare in accordance with the at least one user 
command. 

4. The system of claim 3 wherein said process client 60 
further comprises: 

a process that sorts said travel planning information by 
lowest price based on the user input command. 

5. The system of claim 1 wherein said manipulation 
process further comprises: 65 

a process that finds for the set of pricing solutions a 
pricing solution that optimizes a value function. 
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6. The system of claim 5 wherein said process that finds 
a pricing solution, finds for a travel option a best travel 
option involving an itinerary. 

7. The system of claim 1 wherein the manipulation 
process further comprises: 

an enumerating process that uses the set of pricing solu- 
tions to produce a subset of the set of pricing solutions 
in accordance with a user specified preference. 

8. The system of claim 7 wherein said enumeration 
process further comprises: 

a process that prunes from the set of pricing solutions, a 
set of pricing solutions that do not correspond to a user 
preference. 

9. The system of claim 1 further comprising: 

a server computer for executing said server process; and 
a client computer for executing said client process. 

10. The system of claim 9 further comprising a network 
and wherein said server computer and client computer are 
interconnected by the network. 

11. An airline travel planning system, comprising: 

a scheduler that produces a set of itineraries in response 
to a user specified query; 

a faring system that provides fares for the sets of 
itineraries, and represents the sets of itineraries and 
fares as a set of logically manipulatable nodes in a data 
structure where such nodes are shared across itinerar- 
ies; 

an enumeration process that processes the data structure 
to extract flight-fare components from nodes in the data 
structure. 

12. The system of claim 11 wherein said enumeration 
process further comprises: 

a process that sorts the set of pricing solutions by price in 
accordance with at least one user preference. 

13. The system of claim 11 wherein said process further 
comprises: 

a process that sorts said set of pricing solutions by lowest 
price. 

14. The system of claim 11 wherein the enumeration 
process further comprises: 

a node invalidation process that invalidates nodes in the 
data structure to produce a subset of valid fares linked 
to sets of itineraries in accordance with a user specified 
preference. 

15. The system of claim 11 wherein said enumeration 
process further comprises: 

a process that finds for the set of pricing solutions a 
pricing solution that optimizes a value function. 

16. The system of claim 15 wherein said process finds for 
a travel option a best travel option involving an itinerary. 

17. A travel planning system comprising: 

a server process that in response to at least one travel 
destination and at least one travel origin determines a 
set of pricing solutions, said set of pricing solutions 
represented by a structure that contains a first plurality 
of logically combinable entries that represent a second, 
larger number of pricing solutions; 

a client process that receives said pricing solution 
structure, said client process further comprising: 
an enumeration process that extracts pricing solutions 
from the structure. 

18. The system of claim 17 wherein client process com- 
prises: 

a query process that causes the enumeration process to 
extract pricing solutions from the pricing solution 
structure. 
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19. The system of claim 17 wherein said pricing solution 
structure has a number of logical entries which when logi- 
cally combined can provide a plurality of pricing solutions, 
with the number of set of pricing solutions being larger than 
the number of logical entries in the pricing solution struc- 
ture. 

20. The system of claim 17 wherein said client process 
further comprises: 

a process that produces a sorted set of set of pricing 
solutions by fare in accordance with at least one user 
preference. 

21. The system of claim 17 wherein said client process 
further comprises: 

a process that finds for the set of pricing solutions a 
pricing solution that optimizes a value function. 

22. The system of claim 17 wherein the client process 
further comprises: 

a process that enumerates the set of pricing solutions in 
accordance with a user preference. 

23. The system of claim 17 wherein said process further 
comprises: 

a process that produces a sorted set of said set of pricing 
solutions by lowest price. 

24. The system of claim 23 wherein said process finds for 
a travel option a best travel option involving an itinerary. 

25. The system of claim 24 wherein said enumeration 
process further comprises: 

a process that invalidates logical entries in the pricing 
solution structure. 

26. A travel planning system comprising: 

a server process that in response to at least one travel 
destination and at least one travel origin determines and 
represents a set of pricing solutions by a directed 
acyclic graph data structure; 
a client process that receives said directed acyclic graph, 
said client process further comprising: 
a process that uses the directed acyclic graph represen- 
tation to enumerate in response to user preferences a 
set of pricing solutions. 

27. The system of claim 26 wherein said client process 
further comprises: 

a process that produces a sorted set of pricing solutions by 
price in accordance with at least one user preference. 

28. The system of claim 27 wherein said process that 
produced the sorted set further comprises: 

a process that produces the sorted set of said pricing 
solutions by lowest price. 
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29. The system of claim 26 wherein said client process 
further comprises: 

an extraction process that extracts set of pricing solutions 
from the pricing solution structure. 
5 30. The system of claim 29 wherein said client process 
further comprises: 

an invalidate process that invalidates nodes in the directed 
acyclic graph which are involved only in set of pricing 
10 solutions that are outside of a subset of set of pricing 
solutions. 

31. The system of claim 29 wherein said cheat process 
further comprises: 

a process that finds for the set of pricing solutions a 
15 pricing solution that optimizes a value function. 

32. The system of claim 31 wherein said process that finds 
a pricing solution, finds for a travel option a best travel 
option involving an itinerary. 

33. An airline travel planning system comprising: 
a server computer; 

a server process executed on said server computer, said 
server process comprising a search process to search 
for set of pricing solutions in accordance with at least 
one destination and at least one origin, said search 
process representing said set of pricing solutions in the 
form of a directed acyclic graph; 
a client computer; 

a client computer process responsive to the set of pricing 
solutions represented in the form of the directed acyclic 
graph; 

said client process further comprising: 

a manipulation process that manipulates the set of 
35 pricing solutions in the form of the directed acyclic 

graph representation in response to user preferences, 
said manipulation process comprising: 
a process, responsive to user preferences and to set 
of pricing solutions represented in the directed 
40 acyclic graph, to find a set of pricing solutions in 

accordance with said user preference; 
a process that finds the set of pricing solutions and to 
produce a subset of said set of pricing solutions in 
accordance with user specified preferences; and 
45 a sorting process that prunes from the directed acy- 

clic graph nodes that are no longer contained 
within the subset of set of pricing solutions. 
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